The approach of A/B/C independently generating route to X only based on local
MAC learning works even if physical link failure detection is not an option.
And in most practical cases, X will have enough active flows that it will cause
local learning on A/B/C to hopefully happen well before a fai
> Using a route from another PE (A here) to inject a route by other PEs
> (B/C) has its pitfalls. For instance withdrawals are going to be tough. Say A
> has died for good, and X goes away – what mechanism will invalidate this
> route from B? If it is local-aging at B, then B might as well use
>
Snipped, comment inline.
Yours Irrespectively,
John
What would seem to be better would be for something like a type 2 or DIS to be
used. A, B, and C would all advertise connection to the ES, and then A would
advertise a connection between the ES and each host it knows about, etc. As B
rece
Russ,
Comments inline.
Yours Irrespectively,
John
From: Russ White [mailto:ru...@riw.us]
Sent: Tuesday, February 03, 2015 3:27 PM
To: John E Drake
Cc: Ravi Shekhar; Rabadan, Jorge (Jorge); bess@ietf.org
Subject: Re: [bess] EVPN Draft Comments
I'm on an iPad, so forgive the top post, but this
Hi Russ, please see inline.
From: Russ White [mailto:ru...@riw.us]
Sent: Tuesday, February 03, 2015 12:27 PM
To: John E Drake
Cc: Ravi Shekhar; Rabadan, Jorge (Jorge); bess@ietf.org
Subject: Re: [bess] EVPN Draft Comments
I'm on an iPad, so forgive the top post, but this is what I dug up from an
I'm on an iPad, so forgive the top post, but this is what I dug up from an
email I sent a year+ ago, with some edits added, about aliasing as I understand
it. It was never answered, afaict.
==
Let's say you have PE A, B, and C attached to a single ES. The first problem is
-- under what conditi
Ali:
Ok - I will answer a direct question on the EVPN RFC, and then may we please
stop this thread.
I understood that Russ was referring to the EVPN draft (soon to be RFC
7432). I am not referring to the evpn-overlay draft, and this is not "the
nexthop" issue.This is Auth-48, and the draf
Brian Haberman has entered the following ballot position for
draft-ietf-l3vpn-acceptown-community-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Pleas
Hi Sue,
Two points:
1) What you are saying below and the draft that you mentioned below
(idr-remote-next-hop) is not relevant to baseline EVPN draft (soon to be
RFC 7432).
2) At one point we were thinking of using this draft for evpn-overlay
draft (which is different from baseline evpn); howeve
Alia Atlas has entered the following ballot position for
draft-ietf-l3vpn-acceptown-community-09: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to ht
Stephen Farrell has entered the following ballot position for
draft-ietf-l3vpn-acceptown-community-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Plea
To add to what John said, the remote NH proposal would be less efficient
than the EVPN draft in terms of BGP messaging.
On 03/02/15 13:47, "John E Drake" wrote:
>Sue,
>
>I think we have a tempest in a teapot.
>
>The EVPN Overlay draft
>(https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-00
Ravi,
Thanks but I think you misread my email. I was actually pointing out to Russ
that he hadn't expressed anything more than a visceral dislike for the current
EVPN aliasing design.
Yours Irrespectively,
John
> -Original Message-
> From: Ravi Shekhar
> Sent: Tuesday, February 03,
Sue,
Comments inline.
Yours Irrespectively,
John
> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Tuesday, February 03, 2015 7:28 AM
> To: John E Drake; 'Russ White'; 'Rabadan, Jorge (Jorge)'
> Cc: bess@ietf.org
> Subject: RE: [bess] EVPN Draft Comments
>
> Jo
Russ,
I think the real issue may be some baggage you associate w/ the term 'alias'.
In EVPN, the combination of a Per ES and a Per EVI Ethernet AD route indicates
that the advertising PE has connectivity to a given ES and that the advertised
MPLS label can be used to reach any MAC addresses ass
Sue,
I think we have a tempest in a teapot.
The EVPN Overlay draft
(https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-00) needs to indicate
different data plane encapsulations and initially we had proposed using the RFC
5512 extended community for this.
Subsequently, Ali and Keyur pr
John -
Irrespectively - I cut the email list from the bess@ietf.org working group
and I will not bring it back unless instructed by the BESS WG chairs. The
Base EVPN does not utilize the NLRI/Attributes in a way I consider standard
BGP mechanism to allow scaling or efficient processing. However
> Wrt this draft, the text is very clear as it has been implemented by
several
> major vendors. Now if you are wondering what would be the application for
> variable length, that is outside of the scope of this draft as the draft
clearly
> says that. However, if variable length is used, the length
Sue,
It would be helpful if both you and Russ would offer some specifics. E.g., the
next hop issue that you mentioned in the BESS meeting has nothing to do w/ the
base EVPN spec.
Yours Irrespectively,
John
> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Tues
Ali:
I would be glad to inform Yakov, Keyur and Pedro of these issues I perceive
with the draft. It would be delightful to see why they thought your
structure was reasonable.
Yakov and Pedro have not been in active discussions regarding IDR next-hop
mechanisms in the last year. For 2014, Keyu
Hi Russ, as someone who was involved early on in the EVPN, I can assure you
that we had considered load-balancing as achieved via aliasing early on in the
process. John may not be aware of it because it pre-dates his involvement with
EVPN, but please see section 20.1 of
https://tools.ietf.org/h
21 matches
Mail list logo
