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
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
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
> Minor issues:
> -
>
> As I understand it, if a network only partially supports the new
> (LIR-pF) flag, it doesn't work properly. So we find at the end of
> section 2:
>
> ...the ingress node can conclude
> that the egress node originating that Leaf A-D route does not support
>
Ali, et al:
Sorry for the late comments. I remember reviewing/contributing to this draft
many years ago. Happy to see it is finally moving to IESG Last Call.
The draft describes the mechanism to allow TSs belonging to different subnets
attached to same PE to be communicated by the PE (instead
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.
Title : Explicit Tracking with Wild Card Routes in Multicast
VPN
Authors : Andrew Dolganow
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:
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
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
Hi Eric,
On 2018-10-05 04:15, Eric Rosen wrote:
>> Minor issues:
>> -
>>
>> As I understand it, if a network only partially supports the new
>> (LIR-pF) flag, it doesn't work properly. So we find at the end of
>> section 2:
>>
>> ...the ingress node can conclude
>> that the egress
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
RFC 8214 (EVPN VPWS) introduces a new EVPN Layer 2 Attributes extended
community for signaling the L2 MTU and other control flags, including the
one to signal that the control word needs to be included when sending
packets to this PE. It further describes how MTU checking is to be
performed when
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
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
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:
Hello Everyone,
I have a question on Primary PE encountering a failure in EVPN multihoming
in single active mode.
RFC7432, section 14.1.1:
If there is more than one backup PE for a given ES, the remote PE
MUST use the primary PE's withdrawal of its set of Ethernet A-D per
ES
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
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
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
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
20 matches
Mail list logo
