Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
Agree with John suggestion. Thanks Tapraj From: BESS on behalf of John E Drake Date: Tuesday, October 16, 2018 at 5:43 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" , Zhuangshunwan , Muthu Arul Mozhi Perumal Cc: "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 Jorge, The other possibility for this case is for each PE to advertise a Per EVI Ethernet A-D route for only those EVIs for which it would become DF if the current DF were to fail.. Yours Irrespectively, John From: BESS On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View) Sent: Tuesday, October 16, 2018 4:56 AM To: Zhuangshunwan ; Muthu Arul Mozhi Perumal Cc: jiang...@ericsson.com; p.muthu.arul.mo...@ericsson.com; jaikumar..somasunda...@ericsson.com; bess@ietf.org Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure Hi, RFC7432 explains that if there are more than 2 PEs in the ES, then, upon receiving the AD route withdrawals, the remote PE will flood. That is, it’ll flush the MACs and flood since it does not know who the new DF is, and there is no backup for a given MAC. So yes, with more than 2 PEs, there is no backup per se. Note that, even if we had the BDF indication, upon an ES failure the remote PE will start receiving MAC/IP route withdrawals. Hence unless the re advertisements of the MACs start coming immediately, the BDF indication may not avoid flooding anyway.. We can add the P and B bits here too, but they may not be as useful as in RFC8214. Thanks, Jorge From: Zhuangshunwan mailto:zhuangshun...@huawei.com>> Sent: Tuesday, October 16, 2018 00:19 To: Rabadan, Jorge (Nokia - US/Mountain View); Muthu Arul Mozhi Perumal Cc: jiang...@ericsson.com<mailto:jiang...@ericsson.com>; p.muthu.arul.mo...@ericsson.com<mailto:p.muthu.arul.mo...@ericsson.com>; bess@ietf.org<mailto:bess@ietf.org>; jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com> Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure Hi Jorge, 8.4. Aliasing and Backup Path of RFC7432 says: . The backup path is a closely related function, but it is used in . Single-Active redundancy mode. In this case, a PE also advertises . that it has reachability to a given EVI/ES using the same combination . of Ethernet A-D per EVI route and Ethernet A-D per ES route as . discussed above, but with the "Single-Active" bit in the flags of the . ESI Label extended community set to 1. A remote PE that receives a . MAC/IP Advertisement route with a non-reserved ESI SHOULD consider . the advertised MAC address to be reachable via any PE that has . advertised this combination of Ethernet A-D routes, and it SHOULD . install a backup path for that MAC address. Actually, do we think that the function described in this section only works when there are only 2 PEs in one ES? When there are more than 2 PEs in one ES, it cannot work unless RFC7432 also introduce the BDF election function defined in RFC8214. Regards, Shunwan From: BESS [mailto:bess-boun...@ietf.org] On Behalf OfRabadan, Jorge (Nokia - US/Mountain View) Sent: Friday, October 05, 2018 2:01 PM To: Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>> Cc: jiang...@ericsson.com<mailto:jiang...@ericsson.com>; p.muthu.arul.mo...@ericsson.com<mailto:p.muthu.arul.mo...@ericsson.com>; bess@ietf.org<mailto:bess@ietf.org>; jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com> Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure That should be true only in RFC8214. That’s my point… From:Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>> Date: Friday, October 5, 2018 at 5:47 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" mailto:jorge.raba...@nokia.com>> Cc: "jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com>" mailto:jaikumar.somasunda...@ericsson.com>>, "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, "jiang...@ericsson.com<mailto:jiang...@ericsson.com>" mailto:jiang...@ericsson.com>>, "p.muthu.arul...mo...@ericsson.com<mailto: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 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
Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
I agree John. Thanks, Jorge From: John E Drake Sent: Tuesday, October 16, 2018 07:43 To: Rabadan, Jorge (Nokia - US/Mountain View); Zhuangshunwan; Muthu Arul Mozhi Perumal Cc: jiang...@ericsson.com; p.muthu.arul.mo...@ericsson.com; jaikumar.somasunda...@ericsson.com; bess@ietf.org Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure Jorge, The other possibility for this case is for each PE to advertise a Per EVI Ethernet A-D route for only those EVIs for which it would become DF if the current DF were to fail. Yours Irrespectively, John From: BESS On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View) Sent: Tuesday, October 16, 2018 4:56 AM To: Zhuangshunwan ; Muthu Arul Mozhi Perumal Cc: jiang...@ericsson.com; p.muthu.arul.mo...@ericsson.com; jaikumar.somasunda...@ericsson.com; bess@ietf.org Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure Hi, RFC7432 explains that if there are more than 2 PEs in the ES, then, upon receiving the AD route withdrawals, the remote PE will flood. That is, it’ll flush the MACs and flood since it does not know who the new DF is, and there is no backup for a given MAC. So yes, with more than 2 PEs, there is no backup per se. Note that, even if we had the BDF indication, upon an ES failure the remote PE will start receiving MAC/IP route withdrawals. Hence unless the re advertisements of the MACs start coming immediately, the BDF indication may not avoid flooding anyway.. We can add the P and B bits here too, but they may not be as useful as in RFC8214. Thanks, Jorge From: Zhuangshunwan mailto:zhuangshun...@huawei.com>> Sent: Tuesday, October 16, 2018 00:19 To: Rabadan, Jorge (Nokia - US/Mountain View); Muthu Arul Mozhi Perumal Cc: jiang...@ericsson.com<mailto:jiang...@ericsson.com>; p.muthu.arul.mo...@ericsson.com<mailto:p.muthu.arul.mo...@ericsson.com>; bess@ietf.org<mailto:bess@ietf.org>;jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com> Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure Hi Jorge, 8.4. Aliasing and Backup Path of RFC7432 says: .. The backup path is a closely related function, but it is used in .. Single-Active redundancy mode. In this case, a PE also advertises .. that it has reachability to a given EVI/ES using the same combination .. of Ethernet A-D per EVI route and Ethernet A-D per ES route as .. discussed above, but with the "Single-Active" bit in the flags of the .. ESI Label extended community set to 1. A remote PE that receives a .. MAC/IP Advertisement route with a non-reserved ESI SHOULD consider .. the advertised MAC address to be reachable via any PE that has .. advertised this combination of Ethernet A-D routes, and it SHOULD .. install a backup path for that MAC address. Actually, do we think that the function described in this section only works when there are only 2 PEs in one ES? When there are more than 2 PEs in one ES, it cannot work unless RFC7432 also introduce the BDF election function defined in RFC8214. Regards, Shunwan From: BESS [mailto:bess-boun...@ietf.org]On Behalf OfRabadan, Jorge (Nokia - US/Mountain View) Sent: Friday, October 05, 2018 2:01 PM To: Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>> Cc: jiang...@ericsson.com<mailto:jiang...@ericsson.com>; p.muthu.arul.mo...@ericsson.com<mailto:p.muthu.arul.mo...@ericsson.com>; bess@ietf.org<mailto:bess@ietf.org>;jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com> Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure That should be true only in RFC8214. That’s my point… From:Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail..com>> Date: Friday, October 5, 2018 at 5:47 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" mailto:jorge.raba...@nokia.com>> Cc: "jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com>" mailto:jaikumar.somasunda...@ericsson.com>>, "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, "jiang...@ericsson.com<mailto:jiang...@ericsson.com>" mailto:jiang...@ericsson.com>>, "p.muthu.arul..mo...@ericsson.com<mailto: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 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
Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
Jorge, The other possibility for this case is for each PE to advertise a Per EVI Ethernet A-D route for only those EVIs for which it would become DF if the current DF were to fail. Yours Irrespectively, John From: BESS On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View) Sent: Tuesday, October 16, 2018 4:56 AM To: Zhuangshunwan ; Muthu Arul Mozhi Perumal Cc: jiang...@ericsson.com; p.muthu.arul.mo...@ericsson.com; jaikumar.somasunda...@ericsson.com; bess@ietf.org Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure Hi, RFC7432 explains that if there are more than 2 PEs in the ES, then, upon receiving the AD route withdrawals, the remote PE will flood. That is, it'll flush the MACs and flood since it does not know who the new DF is, and there is no backup for a given MAC. So yes, with more than 2 PEs, there is no backup per se. Note that, even if we had the BDF indication, upon an ES failure the remote PE will start receiving MAC/IP route withdrawals. Hence unless the re advertisements of the MACs start coming immediately, the BDF indication may not avoid flooding anyway.. We can add the P and B bits here too, but they may not be as useful as in RFC8214. Thanks, Jorge From: Zhuangshunwan mailto:zhuangshun...@huawei.com>> Sent: Tuesday, October 16, 2018 00:19 To: Rabadan, Jorge (Nokia - US/Mountain View); Muthu Arul Mozhi Perumal Cc: jiang...@ericsson.com<mailto:jiang...@ericsson.com>; p.muthu.arul.mo...@ericsson.com<mailto:p.muthu.arul.mo...@ericsson.com>; bess@ietf.org<mailto:bess@ietf.org>; jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com> Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure Hi Jorge, 8.4. Aliasing and Backup Path of RFC7432 says: .. The backup path is a closely related function, but it is used in .. Single-Active redundancy mode. In this case, a PE also advertises .. that it has reachability to a given EVI/ES using the same combination .. of Ethernet A-D per EVI route and Ethernet A-D per ES route as .. discussed above, but with the "Single-Active" bit in the flags of the .. ESI Label extended community set to 1. A remote PE that receives a .. MAC/IP Advertisement route with a non-reserved ESI SHOULD consider .. the advertised MAC address to be reachable via any PE that has .. advertised this combination of Ethernet A-D routes, and it SHOULD .. install a backup path for that MAC address. Actually, do we think that the function described in this section only works when there are only 2 PEs in one ES? When there are more than 2 PEs in one ES, it cannot work unless RFC7432 also introduce the BDF election function defined in RFC8214. Regards, Shunwan From: BESS [mailto:bess-boun...@ietf.org] On Behalf OfRabadan, Jorge (Nokia - US/Mountain View) Sent: Friday, October 05, 2018 2:01 PM To: Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>> Cc: jiang...@ericsson.com<mailto:jiang...@ericsson.com>; p.muthu.arul.mo...@ericsson.com<mailto:p.muthu.arul.mo...@ericsson.com>; bess@ietf.org<mailto:bess@ietf.org>; jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com> Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure That should be true only in RFC8214. That's my point... From:Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail..com>> Date: Friday, October 5, 2018 at 5:47 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" mailto:jorge.raba...@nokia.com>> Cc: "jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com>" mailto:jaikumar.somasunda...@ericsson.com>>, "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, "jiang...@ericsson.com<mailto:jiang...@ericsson.com>" mailto:jiang...@ericsson.com>>, "p.muthu.arul..mo...@ericsson.com<mailto: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 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) mailto:jorge.raba...@nokia.com>> wrote: Muthu, From:Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail..com>> Date: Thursday, October 4, 2018 at 5:37 PM To: "Rabadan, Jorge (Nokia - US/Mountain View)" mailto:jorge.raba...@nokia.com>> Cc: "jaikumar.somasunda...@ericsson.com<mailt
Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
Hi, RFC7432 explains that if there are more than 2 PEs in the ES, then, upon receiving the AD route withdrawals, the remote PE will flood. That is, it’ll flush the MACs and flood since it does not know who the new DF is, and there is no backup for a given MAC. So yes, with more than 2 PEs, there is no backup per se. Note that, even if we had the BDF indication, upon an ES failure the remote PE will start receiving MAC/IP route withdrawals. Hence unless the re advertisements of the MACs start coming immediately, the BDF indication may not avoid flooding anyway. We can add the P and B bits here too, but they may not be as useful as in RFC8214. Thanks, Jorge From: Zhuangshunwan Sent: Tuesday, October 16, 2018 00:19 To: Rabadan, Jorge (Nokia - US/Mountain View); Muthu Arul Mozhi Perumal Cc: 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, 8.4. Aliasing and Backup Path of RFC7432 says: .. The backup path is a closely related function, but it is used in .. Single-Active redundancy mode. In this case, a PE also advertises .. that it has reachability to a given EVI/ES using the same combination .. of Ethernet A-D per EVI route and Ethernet A-D per ES route as .. discussed above, but with the "Single-Active" bit in the flags of the .. ESI Label extended community set to 1. A remote PE that receives a .. MAC/IP Advertisement route with a non-reserved ESI SHOULD consider .. the advertised MAC address to be reachable via any PE that has .. advertised this combination of Ethernet A-D routes, and it SHOULD .. install a backup path for that MAC address. Actually, do we think that the function described in this section only works when there are only 2 PEs in one ES? When there are more than 2 PEs in one ES, it cannot work unless RFC7432 also introduce the BDF election function defined in RFC8214. Regards, Shunwan From: BESS [mailto:bess-boun...@ietf.org] On Behalf OfRabadan, Jorge (Nokia - US/Mountain View) Sent: Friday, October 05, 2018 2:01 PM To: Muthu Arul Mozhi Perumal Cc: 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 That should be true only in RFC8214. That’s my point… From:Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail..com>> Date: Friday, October 5, 2018 at 5:47 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" mailto:jorge.raba...@nokia.com>> Cc: "jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com>" mailto:jaikumar.somasunda...@ericsson.com>>, "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, "jiang...@ericsson.com<mailto:jiang...@ericsson.com>" mailto:jiang...@ericsson.com>>, "p.muthu.arul.mo...@ericsson.com<mailto: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 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) mailto:jorge.raba...@nokia.com>> wrote: Muthu, From:Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail..com>> Date: Thursday, October 4, 2018 at 5:37 PM To: "Rabadan, Jorge (Nokia - US/Mountain View)" mailto:jorge.raba...@nokia.com>> Cc: "jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com>" mailto:jaikumar.somasunda...@ericsson.com>>, "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, "jiang...@ericsson.com<mailto:jiang...@ericsson.com>" mailto:jiang...@ericsson.com>>, "p.muthu.arul.mo...@ericsson.com<mailto: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 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 oth
Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
Hi Jorge, 8.4. Aliasing and Backup Path of RFC7432 says: . The backup path is a closely related function, but it is used in . Single-Active redundancy mode. In this case, a PE also advertises . that it has reachability to a given EVI/ES using the same combination . of Ethernet A-D per EVI route and Ethernet A-D per ES route as . discussed above, but with the "Single-Active" bit in the flags of the . ESI Label extended community set to 1. A remote PE that receives a . MAC/IP Advertisement route with a non-reserved ESI SHOULD consider . the advertised MAC address to be reachable via any PE that has . advertised this combination of Ethernet A-D routes, and it SHOULD . install a backup path for that MAC address. Actually, do we think that the function described in this section only works when there are only 2 PEs in one ES? When there are more than 2 PEs in one ES, it cannot work unless RFC7432 also introduce the BDF election function defined in RFC8214. Regards, Shunwan From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View) Sent: Friday, October 05, 2018 2:01 PM To: Muthu Arul Mozhi Perumal Cc: 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 That should be true only in RFC8214. That’s my point… From: Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>> Date: Friday, October 5, 2018 at 5:47 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" mailto:jorge.raba...@nokia.com>> Cc: "jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com>" mailto:jaikumar.somasunda...@ericsson.com>>, "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, "jiang...@ericsson.com<mailto:jiang...@ericsson.com>" mailto:jiang...@ericsson.com>>, "p.muthu.arul.mo...@ericsson.com<mailto: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 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) mailto:jorge.raba...@nokia.com>> wrote: Muthu, From: Muthu Arul Mozhi Perumal mailto:muthu.a...@gmail.com>> Date: Thursday, October 4, 2018 at 5:37 PM To: "Rabadan, Jorge (Nokia - US/Mountain View)" mailto:jorge.raba...@nokia.com>> Cc: "jaikumar.somasunda...@ericsson.com<mailto:jaikumar.somasunda...@ericsson.com>" mailto:jaikumar.somasunda...@ericsson.com>>, "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, "jiang...@ericsson.com<mailto:jiang...@ericsson.com>" mailto:jiang...@ericsson.com>>, "p.muthu.arul.mo...@ericsson.com<mailto: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 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 ta
Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
Hi Jai, I think draft-ietf-bess-evpn-df-election-framework-03 section-3.1 might help. Thanks & Regards Tim From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Jaikumar Somasundaram Sent: 05 October 2018 06:07 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 find further question below. From: Rabadan, Jorge (Nokia - US/Mountain View)
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) 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
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
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
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 wit
Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
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>" mailto:jaikumar.somasunda...@ericsson.com>>, "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, "jiang...@ericsson.com<mailto:jiang...@ericsson.com>" mailto:jiang...@ericsson.com>>, "p.muthu.arul.mo...@ericsson.com<mailto: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>" 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.so
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 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>" 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 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 F
Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
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>" mailto:jaikumar.somasunda...@ericsson.com>>, "bess@ietf.org<mailto:bess@ietf.org>" mailto:bess@ietf.org>>, "jiang...@ericsson.com<mailto:jiang...@ericsson.com>" mailto:jiang...@ericsson.com>>, "p.muthu.arul.mo...@ericsson.com<mailto: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>" 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. 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 f
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>" 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
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. > >
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? 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: *Thurs
Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
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>" 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. 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>" 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
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 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>" 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
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
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
Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
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>" 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
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
