HI Weigo, all,
Let me try to help again...
RFC7432, section 8.5 says:
If a bridged network is multihomed to more than one PE in an EVPN
network via switches, then the support of All-Active redundancy mode
requires the bridged network to be connected to two or more PEs using
a LAG.
If a bridged network does not connect to the PEs using a LAG, then
only one of the links between the bridged network and the PEs must be
the active link for a given <ES, VLAN> or <ES, VLAN bundle>. In this
case, the set of Ethernet A-D per ES routes advertised by each PE
MUST have the "Single-Active" bit in the flags of the ESI Label
extended community set to 1.
My understanding was that the above excludes the kind of topology in
which you exclude a possible loop.
-Thomas
Weiguo :
Hi John,
If you can tolerate indefinite forwarding loop during transiet time, i have no
problem. If the community think it is a serious problem, i think we must
propose an applicable solution for it, maybe there are other solutions better
than handshaking mechanism.
Thanks,
weiguo
________________________________________
From: John E Drake [[email protected]]
Sent: Friday, March 27, 2015 23:22
To: Haoweiguo; Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT -
[email protected]; [email protected]
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm
I think we have beaten this topic to death. For the numerous reason I've
given, I'm not interested in you proposal.
Yours Irrespectively,
John
-----Original Message-----
From: BESS [mailto:[email protected]] On Behalf Of Haoweiguo
Sent: Friday, March 27, 2015 11:12 AM
To: Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT -
[email protected]; [email protected]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm
Hi Jorge,
Let give you another indefinitely forwarding loop case, the picture is as
follows:
CE3------------CE4
| |
PE3 PE4
PE1 PE2
| |
CE1------------CE2
If PE1 and PE2 are dual DF PE in transiet time, assuing PE3 and PE4 are in
stable state ,PE3 is DF PE, PE4 is non-DF PE, the BUM traffic from CE3 to CE1,
the forwarding loop path is as follows;
CE3--->PE3------>PE2--->CE2---->CE1---->PE1---->PE3-->CE3-->CE4--->PE4----
forever......
Do you think the harm is enough?
Thanks,
weiguo
________________________________________
From: Rabadan, Jorge (Jorge) [[email protected]]
Sent: Friday, March 27, 2015 22:59
To: Haoweiguo; Satya Mohanty (satyamoh); [email protected];
[email protected]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm
Hi Weiguo,
OK, thanks for clarifying, that is the part I did not understand in your loop
:-)
To me a loop means you send a frame and that frame keeps being forwarded
by the same nodes indefinitely till you take a corrective action.
In this case, CE3 might get a few packets during the transient state, but those
packets will have its own MAC SA so CE3 will discard them. I don't think that is
harmful for CE3 in most of the cases. And if it is, you just need to make sure
the timers are long enough and the DF election properly implemented to
avoid the transient DF-DF state.
The handshaking is definitely overkilling IMHO.
Thanks.
Jorge
-----Original Message-----
From: Haoweiguo <[email protected]>
Date: Friday, March 27, 2015 at 7:29 AM
To: Jorge Rabadan <[email protected]>, "Satya Mohanty
(satyamoh)" <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm
Hi Jorge,
Sorry, maybe i have not explain clearly, pls allow me to clarify it
more clearly.
In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2, CE2
is single homed to remote PE3. CE1 and CE2 forms one layer 2 network,
so it multi-homed network scenario.
CE3
|
PE3
PE1 PE2
| |
CE1-----------CE2
In transiet period, PE1 and PE2 are both DF PE. At this time, CE3 sends
BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1 will
receive two copy of the traffic from CE3, also loop is formed, the form path:
CE3---->PE3---->PE2---->CE2---->CE1---->PE1--->PE3--->CE3
I think the traffic loop is absolutely not allowed. In MHN case, the
loop will formed due to dual-DF PE in transiet period.
Thanks,
weiguo
________________________________________
From: Rabadan, Jorge (Jorge) [[email protected]]
Sent: Friday, March 27, 2015 20:26
To: Haoweiguo; Satya Mohanty (satyamoh); [email protected];
[email protected]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm
Hi Weiguo,
About this:
[weiguo]: Traffic duplication and loop issue both exist in dual DF PE
case. In multi-homed device case, say CE1 is multi-homed to PE1 and PE2
and both PE are DF PE. When CE1 sends traffic to PE1, the traffic will
loop back to CE1 through PE2. If CE1 can filter and drop the traffic ,
it is fortunate, maybe no loop.
For multi-homed network scenario, say local network1(CE1 and CE2) is
multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will loop
back through PE1-->PE2-->CE2, it is very serious. It is absolutely not allowed.
[JORGE] In a MH device case: CE1->BUM->PE1->(ESI-label+BUM)->PE2. PE2
will not send the traffic back to CE1 due to the ESI-label and
split-horizon procedures.
In MH network case PE2 will NOT send the traffic to CE2 for the same
reason.
Let me know if you disagree please.
Thanks.
Jorge
-----Original Message-----
From: Haoweiguo <[email protected]>
Date: Thursday, March 26, 2015 at 9:55 PM
To: "Satya Mohanty (satyamoh)" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm
Hi Satya,
Pls see inline.
Thanks,
weiguo
________________________________________
From: Satya Mohanty (satyamoh) [[email protected]]
Sent: Friday, March 27, 2015 12:11
To: Haoweiguo; [email protected]; [email protected]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm
Thomas,
Thanks for your summary. It captures the essence of the discussion.
[weiguo]: Yes, i agree.
One feature of the HRW scheme is that it computes the Active and the
Backup DF upfront.
Whenever the Active PE, say PE1, dies; the Backup PE, PE2, can become
the Active immediately upon receiving the withdraw of the ES route
>from PE1.
It need not even have to wait for the 3 seconds time.
[weiguo]: I think maybe your negligence, dies PE1 can't send withdraw
message:) But when PE1 leaves ESI, it can withdraw the ES route
immediately.
When PE1 dies and recovers, assuming PE1 is DF PE, then PE1 and PE2
will both act as PE for some transiet time.
On the other hand, the 3 second timer will serve as a bulk and batch
mechanism for the case when new PE(s) is(are) coming up, so we don¹t
have to do a DF election ever so often.
Haoweiguo, I think the "loop" scenario is speculative.
I think everybody understands that, yes, there may be some transient
duplication of bum traffic; however, there is no "loop" problem to be
solved.
[weiguo]: Traffic duplication and loop issue both exist in dual DF PE
case. In multi-homed device case, say CE1 is multi-homed to PE1 and
PE2 and both PE are DF PE. When CE1 sends traffic to PE1, the traffic
will loop back to CE1 through PE2. If CE1 can filter and drop the
traffic , it is fortunate, maybe no loop.
For multi-homed network scenario, say local network1(CE1 and CE2) is
multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will loop
back through PE1-->PE2-->CE2, it is very serious. It is absolutely not
allowed.
Thanks,
--Satya
On 3/26/15 9:08 PM, "Haoweiguo" <[email protected]> wrote:
Hi Thomas,
I know you are neutral, sorry for my reply vulnerable to be
miunderstood.
Thanks,
weiguo
________________________________________
From: [email protected] [[email protected]]
Sent: Friday, March 27, 2015 11:59
To: Haoweiguo; [email protected]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm
Hi Weiguo,
2015-03-26, Haoweiguo:
Thomas:
- RFC7432 may have transient periods where the DF election state
is not yet synchronized between the two peers:
[weiguo]: Yes, i think RFC 7432 has transient periods of traffic
loop
Note well that I didn't write that there can be transient _loops_ .
I tried to capture the exchange you had all, and what I gather is
that the split-horizon procedure _prevents_loops_, independently of
any transient period where DF state is not synchronized and which may
lead to transient _duplicates_.
-Thomas
26/03/2015 20:05, John E Drake :
Weiguo,
I guess I wasn¹t clear. I think you draft, for the reasons I have
detailed, is a non-solution to a non-problem with tremendous
control plane cost.
Yours Irrespectively,
John
*From:*Haoweiguo [mailto:[email protected]]
*Sent:* Thursday, March 26, 2015 6:17 PM
*To:* John E Drake; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); [email protected]
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm
Pls see below.
Thanks,
weiguo
-------------------------------------------------------------------
---
-
-
*From:*John E Drake [[email protected]]
*Sent:* Friday, March 27, 2015 6:00
*To:* Haoweiguo; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]>
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm
To recap,
We have established that your proposal is untenable because of its
control plane load.
We have established that your proposal is based upon a flawed
understanding of the DF election in RFC 7432.
[weiguo]: In ethernet world, traffic loop is serious than short
timer traffic disruption. If you want to implement transiet
traffic loop process, i will modify my draft to solve your issue.
If i am the developer, i will prefer short timer traffic
disruption based on current EVPN protocol.
What you are now arguing is that your draft prevents two or more
PEs from being DF simultaneously. This is clearly nonsense.
[weiguo]: I will modify the draft problem statements, and use the
same handshaking solution to solve it.
Furthermore, we have established that having two or more DFs for
what even you admit is a brief transient leads to duplicate
traffic, which is acceptable, but not loops, your assertion to the
contrary.
[weiguo]: It is transient loop and traffic duplication issue.
Yours Irrespectively,
John
*From:*Haoweiguo [mailto:[email protected]]
*Sent:* Thursday, March 26, 2015 5:37 PM
*To:* John E Drake; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]>
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm
John,
As your understanding of the EVPN draft, the DF election mechanism
has more serious side effect, it will have short time traffic
loop,i.e., dual DF PEs will exist for a short time. I think dual
DF PEs is absolutely not tolerated, because native ethernet header
has no TTL, up to several hundred ms traffic loop normally not
tolerated in commertial networks.
As your understanding, the PEs should do as following:
1. Accurate timer sync. NTP accuracy is bad, 1588v2 is good but
have rarely deployment.
Assuming PE1,PE2 and PE3 have consistent timer clock, when PE3
joins ESI and trigger DF re-election. When reception timer expires:
PE1 upgrades to DF PE.
After reception timer+ ES route transmission timer:
PE2 downloads to non-DF PE.
So in timer clock sync case, dual DF PEs will exist at least
transmission timer.
If NTP is used for timer sync, because it has bad accuracy, dual
DF PEs will exist more longer timer.
So as your understanding for DF election, the drawback is more clear.
Thanks,
weiguo
-------------------------------------------------------------------
---
-
-
*From:*John E Drake [[email protected]]
*Sent:* Friday, March 27, 2015 4:41
*To:* Haoweiguo; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]>
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm
Weiguo,
We have already established that your proposal is untenable
because of its control plane load.
What we are now discussing is that your proposal is based upon a
misunderstanding of the algorithm in RFC 7432. You are assuming
that
PE1 will advertise an ES route and then wait for the configured
interval before performing the DF election while PE2 and PE3 will
perform the DF election as soon as they receive the ES route from
PE1.
This is not what RFC 7432 says.
Rather, what is says is that the advertisement of the ES route by
PE1 and its receipt by PE2 and PE3 causes all three PEs to start
the configured interval timer - ³3. When the timer expires, each
PE builds an ordered list of the IP addresses of all the PE nodes
connected to the Ethernet segment (including itself), in
increasing numeric value.²
Yours Irrespectively,
John
*From:*Haoweiguo [mailto:[email protected]]
*Sent:* Thursday, March 26, 2015 3:26 PM
*To:* John E Drake; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]>
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm
Pls read my detail replies to Satya. If you still can't catch it,
pls read my draft and EVPN base protocol, thanks
weiguo
-------------------------------------------------------------------
---
-
-
*From:*John E Drake [[email protected]]
*Sent:* Friday, March 27, 2015 1:28
*To:* Patrice Brissette (pbrisset)
*Cc:* Haoweiguo; Ali Sajassi (sajassi); [email protected]
<mailto:[email protected]>
*Subject:* Re: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm
I think Patrice is correct. Your proposal doesn't solve the
problem and it does so at huge cost.
Sent from my iPhone
On Mar 26, 2015, at 10:34 AM, Patrice Brissette (pbrisset)
<[email protected] <mailto:[email protected]>> wrote:
Weiguo,
I¹m not sure I¹m following here.
Don¹t you have the same issue with your handshaking mechanism?
If you don¹t know your peer, how can you handshake?
Regards,
Patrice
Image removed by sender.
*Patrice Brissette*
TECHNICAL LEADER.ENGINEERING
[email protected] <mailto:[email protected]>
Phone: *+1 613 254 3336*
*Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE*
Canada
Cisco.com <http://www.cisco.com/global/CA/>
Image removed by sender.Think before you print.
This email may contain confidential and privileged material for
the sole use of the intended recipient. Any review, use,
distribution or disclosure by others is strictly prohibited. If
you are not the intended recipient (or authorized to receive for
the recipient), please contact the sender by reply email and
delete all copies of this message.
Please click here
<http://www.cisco.com/web/about/doing_business/legal/cri/index.h
tml>
for Company Registration Information.
*From: *Haoweiguo <[email protected]
<mailto:[email protected]>>
*Date: *Thursday, March 26, 2015 at 10:24 AM
*To: *Patrice Brissette <[email protected]
<mailto:[email protected]>>, John E Drake <[email protected]
<mailto:[email protected]>>, Ali Sajassi <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected] <mailto:[email protected]>>
*Subject: *RE: [bess] Handshaking among PEs in an EVPN ES
based on
Paxos algorithm
Hi Patrice,
Up to reception timer traffic disruption in transient
phase is
one of the issues.
Thanks,
weiguo
-------------------------------------------------------------------
---
-
-
*From:*Patrice Brissette (pbrisset) [[email protected]
<mailto:[email protected]>]
*Sent:* Thursday, March 26, 2015 20:54
*To:* Haoweiguo; John E Drake; Ali Sajassi (sajassi);
[email protected] <mailto:[email protected]>
*Subject:* Re: [bess] Handshaking among PEs in an EVPN ES
based on Paxos algorithm
Weiguo,
You mention "But if your draft have not solved all
issues²,
Can you explain what Satya¹s draft is not solving?
Regards,
Patrice
Image removed by sender.
*Patrice Brissette*
TECHNICAL LEADER.ENGINEERING
[email protected] <mailto:[email protected]>
Phone: *+1 613 254 3336*
*Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE*
Canada
Cisco.com <http://www.cisco.com/global/CA/>
Image removed by sender.Think before you print.
This email may contain confidential and privileged material
for the sole use of the intended recipient. Any review, use,
distribution or disclosure by others is strictly prohibited.
If you are not the intended recipient (or authorized to
receive for the recipient), please contact the sender by
reply
email and delete all copies of this message.
Please click here
<http://www.cisco.com/web/about/doing_business/legal/cri/index.h
tml>
for Company Registration Information.
*From: *Haoweiguo <[email protected]
<mailto:[email protected]>>
*Date: *Wednesday, March 25, 2015 at 10:38 PM
*To: *John E Drake <[email protected]
<mailto:[email protected]>>, Ali Sajassi <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
*Subject: *Re: [bess] Handshaking among PEs in an EVPN ES
based on Paxos algorithm
Hi John,
Firstly i think EVPN community should reach
consensus on
the issues of current DF election mechanism. All these
issues should be resolved in a single new DF election
draft,rather than in multiple separate drafts. If your
draft can solve all these issues and stable, i have no
question for its progressing. But if your draft have not
solved all issues, i think it had better combine with
other drafts to provide a comprehensive solution. I
think
the issues listed in draft-rabadan-bess-evpn-ac-df-01
and
draft-hao-bess-evpn-df-handshaking-00 is valid, it
should
be resolved. So i think although your new Hash algorithm
for DF election is good, it only includes partial
enhancements, maybe it still needs some time for
consensus.
Thanks,
weiguo
-------------------------------------------------------------------
---
-
-
*From:*John E Drake [[email protected]
<mailto:[email protected]>]
*Sent:* Thursday, March 26, 2015 7:16
*To:* Haoweiguo; Ali Sajassi (sajassi); [email protected]
<mailto:[email protected]>
*Subject:* RE: [bess] Handshaking among PEs in an
EVPN ES
based on Paxos algorithm
Weiguo,
Your proposal introduces a control plane processing load
that is O(#EVIs * PEs) per DF election and given that
there can be 4K EVIs per ES, this looks like a
**substantial** load. Furthermore,
you can¹t use the ES route to co-ordinate DF election
because you would need to carry your new extended
community for each EVI and they would not all fit. You
also can¹t use the Per EVI Ethernet AD route because
that
is processed by all PEs in the EVI.
I think that from a practical perspective the new DF
election proposed in Satya¹s draft is sufficiently
stable
that it renders your draft moot, even if it could be
made
to work.
Yours Irrespectively,
John
*From:*BESS [mailto:[email protected]] *On Behalf Of
*Haoweiguo
*Sent:* Wednesday, March 25, 2015 5:34 PM
*To:* Ali Sajassi (sajassi); [email protected]
<mailto:[email protected]>
*Subject:* Re: [bess] Handshaking among PEs in an
EVPN ES
based on Paxos algorithm
Hi Ali,
Thanks for your information. I scanned through this
draft,
it really introduces inter-chassis message for DF
election
handshaking, the requirements in this draft is to
eliminate transiet Loop and traffic duplication. Current
EVPN DF election mechanism already eliminated loop and
traffic duplication by configuring long reception
timer on
each multi-homed PE, but up to reception timer traffic
disruption issue still exist. EVPN for DCI is an
important
use case for EVPN, up to reception timer traffic
disruption can't be tolerated for service providers, it
should be improved.
Also for accuracy, i think handshaking state machine on
each multi-homed PE is also needed. From solution
perspective, in my draft, no inter-chassis message is
introduced, only one new extended community is
introduced,
i think the process is comparatively simple than your
following draft.
Current EVPN DF election has some drawbacks, so there
are
three new drafts about DF election emerged. I think BESS
WG can consider these three drafts in global view, a
single,comprehensive new DF election draft is hoped.
thanks.
Thanks,
weiguo
-------------------------------------------------------------------
---
-
-
*From:*BESS [[email protected]
<mailto:[email protected]>] on behalf of Ali Sajassi
(sajassi) [[email protected] <mailto:[email protected]>]
*Sent:* Thursday, March 26, 2015 0:21
*To:* [email protected] <mailto:[email protected]>
*Subject:* [bess] Handshaking among PEs in an EVPN ES
based on Paxos algorithm
FYI- First published July 4, 2011
https://datatracker.ietf.org/doc/draft-sajassi-l2vpn-evpn-segment-r
out
e
/
-Ali
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
______________________________________________________
______________
___
_
_
________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre
diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler a l'expediteur et le
detruire ainsi que les pieces jointes. Les messages electroniques
etant susceptibles d'alteration, Orange decline toute
responsabilite si ce message a ete altere, deforme ou falsifie.
Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law; they should
not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender
and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that
have been modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________________
______________
___
_
_
_______________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message
par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
que les pieces jointes. Les messages electroniques etant susceptibles
d'alteration, Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law; they should not
be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender
and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
