Subject: [bess] REG: draft-mohanty-bess-evpn-df-election-02

From: "sudeep g ggg" <[email-masked]>
Date: 22 Nov 2015 06:21:13 -0000

Respected Authors,

I am having 2 use cases based on that, I have a couple of queries. Correct me if I am wrong or If I am missing something.Your input is highly appreciating.

1. When a new PE comes in the MH segment.
2. When a PE is brought down due to MW(Maintenance window).

As per the above use cases.There will be change in DF election process. And for 3 seconds there is chance of transient loop.There is delay of bgp update received by each PE.Kindly let me know whether this is taken care.
Moreover 3 seconds if the traffic is blocked in the network creates problem for delay sensitive traffic like voice,images etc.

May I know about your views in above cases.

Regards,
Sudhin

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Tue, 24 Nov 2015 02:53:21 +0000

Sudeep,

Why do you think there will be a loop? Per ES EAD route carry ESI-mpls extcomm which has a split-horizon label to avoid such problem. I think also it depends on how your configure your router (in what order).
In the case of PBB-EVPN, it is taken care by the nature of PBB.

Regards,

Patrice

   [http://www.cisco.com/web/europe/images/email/signature/est2014/logo_06.png?ct=1406640631632]

Patrice Brissette
TECHNICAL LEADER.ENGINEERING

[email-masked]<mailto:[email-masked]>
Phone: +1 613 254 3336

Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Canada
Cisco.com<http://www.cisco.com/global/CA/>

[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] 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.html> for Company Registration Information.

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of sudeep g ggg <[email-masked]<mailto:[email-masked]>>
Date: Sunday, November 22, 2015 at 1:21 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [bess] REG: draft-mohanty-bess-evpn-df-election-02

Respected Authors,

Regards,
Sudhin

[https://sigads.rediff.com/RealMedia/ads/adstream_nx.ads/www.rediffmail.com/signatureline.htm@Middle]<https://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle?>
Get your own FREE website, FREE domain & FREE mobile app with Company email.
        Know More ><http://track.rediff.com/click?url=___http://businessemail.rediff.com?sc_cid=sign-1-10-13___&cmp=host&lnk=sign-1-10-13&nsrv1=host>

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Tue, 24 Nov 2015 03:25:09 +0000

Hi Sudeep,

Please see inline [Satya].
Patrice, thanks for your observation.

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of "Patrice Brissette (pbrisset)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 23, 2015 6:53 PM
To: sudeep g ggg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] REG: draft-mohanty-bess-evpn-df-election-02

Sudeep,

Regards,

Patrice

Patrice Brissette

Respected Authors,

1. When a new PE comes in the MH segment.
[Satya] Yes, New PE needs to wait for 3 sec. According to RFC 7438, the receiving PEs also need to wait for 3 secs. But, ideally, a PE that is going from DF to non-DF or non-DF to non-DF should become the non-DF rightaway. Only the PE that is going DF really needs to wait for 3 secs. This is not explicitly spelled out in the draft but we are thinking along these lines.

Now, delay of BGP updates is not dependent on the above behavior. That depends on the network topology and queueing/processing at intermediate nodes.
With HRW,  a PE coming up will result in minimal disruption of the established DF for various vlans (bundles) as opposed to RFC 7438 mod-based.

2. When a PE is brought down due to MW(Maintenance window).
[Satya] As per the HRW, if this PE was not the DF for a vlan (vlan-bundle) this should have no effect on the DF election.
This is where it again performs better than the RFC 7438 modulo-based algorithm.
If this was the DF, then some other surviving PE, say PE' for which the Hash(PE', vlan) is maximum can become the PE right away on receiving the BGP withdraw.
There is no need for a three second wait.

Regards,
Sudhin

---

From: "sudeep g ggg" <[email-masked]>
Date: 24 Nov 2015 05:20:44 -0000

Respected Satya,

Let me thank you for the mail. IT is much appreciated. May I request you to look in to my reply named "sudhin". If this is already taken care my sincere apologies for asking redundant question.

Regards,
Sudhin Jacob

Sudhin>> you are correct Satya but how to deal with traffic for 3 seconds when a new type 4 route comes. DF election kicks in and all PE's, For 3 seconds how to deal with traffic, the state machines need to be updated like blocking traffic or forwarding. if  during that time the traffic is forwarded then a loop will be created. the EVPN RFC says SH label and BUM drop after the election, but correct me if I am totally wrong during the transition how to deal is not covered.I request your valid input on this. How to deal in that situation,what is the state of PE's during 3 seconds period.How to reach a consensus between vendors. Say for example vendors design custom solution to handle this, then how the inter op between vendors will not work.

On Tue, 24 Nov 2015 08:55:20 +0530 "Satya Mohanty (satyamoh)"  wrote

Hi Sudeep,

From: BESS  on behalf of "Patrice Brissette (pbrisset)" 

To: sudeep g ggg , "[email-masked]" 

Sudeep,

Regards,

Patrice

Patrice Brissette

[email-masked]

Phone: +1 613 254 3336

Canada

Cisco.com

 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 for Company Registration Information.

From: BESS  on behalf of sudeep g ggg 

To: "[email-masked]" 

Respected Authors,

[Satya] Yes, New PE needs to wait for 3 sec. According to RFC 7438, the receiving PEs also need to wait for 3 secs. But, ideally, a PE that is going from DF to non-DF or non-DF to non-DF should become the non-DF rightaway. Only the
 PE that is going DF really needs to wait for 3 secs. This is not explicitly spelled out in the draft but we are thinking along these lines.

Regards,

Sudhin

Get your own

FREE website, 
FREE domain & 
FREE mobile app with Company email. 

Know
 More >

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 24 Nov 2015 05:52:58 +0000

Sudhin>> you are correct Satya but how to deal with traffic for 3 seconds when a new type 4 route comes. DF election kicks in and all PE's, For 3 seconds how to deal with traffic, the state machines need to be updated like blocking traffic or forwarding. if during that time the traffic is forwarded then a loop will be created. the EVPN RFC says SH label and BUM drop after the election, but correct me if I am totally wrong during the transition how to deal is not covered.I request your valid input on this. How to deal in that situation,what is the state of PE's during 3 seconds period.How to reach a consensus between vendors. Say for example vendors design custom solution to handle this, then how the inter op between vendors will not work.
[Tony saiz:] The FSM clarifies that. No DF is given up on arrival of new ES routes.

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Tue, 24 Nov 2015 19:01:25 +0000

Hi Sudeep,

I think when a new PE is brought up to a redundancy group, the related forwarding must be blocked.

Regards,

Patrice

Patrice Brissette

From: <[email-masked]<mailto:[email-masked]>> on behalf of sudeep g ggg <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 24, 2015 at 12:20 AM
To: "Satya Mohanty (satyamoh)" <[email-masked]<mailto:[email-masked]>>
Cc: Patrice Brissette <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] REG: draft-mohanty-bess-evpn-df-election-02

Respected Satya,

Regards,
Sudhin Jacob

Hi Sudeep,

To: sudeep g ggg , "[email-masked]<mailto:[email-masked]>"

Sudeep,

Regards,

Patrice

Patrice Brissette

Phone: +1 613 254 3336

Canada

Cisco.com

Think before you print.

To: "[email-masked]<mailto:[email-masked]>"

Respected Authors,

Regards,

Sudhin

Get your own

FREE website,
FREE domain &

Know
More >

---

From: Kishore Tiruveedhula <[email-masked]>
Date: Tue, 24 Nov 2015 20:42:26 +0000

Please see below inline...[Kishore].

[Kishore]  Yes. The new PE need to wait for 3 seconds, but if new PE receives the type 4 route from the redundant PE before 3 seconds, the new PE can just move to DF immediately (if it becomes DF) just after receiving the type 4 without waiting for the 3 seconds timer expiry because the other redundant PE might have moved to Non-DF as there is no 3 seconds timer on the other PE which is moving from DF to Non-DF.
It is good idea to explicitly spell out this in this draft.

[Satya] Now, delay of BGP updates is not dependent on the above behavior. That depends on the network topology and queueing/processing at intermediate nodes.
With HRW,  a PE coming up will result in minimal disruption of the established DF for various vlans (bundles) as opposed to RFC 7438 mod-based.

[Kishore] If the BGP update processing takes more time on one PE and receives less time from RR on the other PE, then it may be possible of both PE may become DF or Non-DF, so the timer value should be chosen large enough in this case.

Thanks,
Kishore

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Tue, 24 Nov 2015 22:11:49 +0000

Hi Kishore/Sudhin,

From: Kishore Tiruveedhula <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 24, 2015 12:42 PM
To: smohanty mohanty <[email-masked]<mailto:[email-masked]>>, "Patrice Brissette (pbrisset)" <[email-masked]<mailto:[email-masked]>>, sudeep g ggg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] REG: draft-mohanty-bess-evpn-df-election-02

[Kishore]  Yes. The new PE need to wait for 3 seconds, but if new PE receives the type 4 route from the redundant PE before 3 seconds, the new PE can just move to DF immediately (if it becomes DF) just after receiving the type 4 without waiting for the 3 seconds timer expiry because the other redundant PE might have moved to Non-DF as there is no 3 seconds timer on the other PE which is moving from DF to Non-DF.
It is good idea to explicitly spell out this in this draft.
[Satya] Right. We will spell this out in the next version.

[Kishore] If the BGP update processing takes more time on one PE and receives less time from RR on the other PE, then it may be possible of both PE may become DF or Non-DF, so the timer value should be chosen large enough in this case.
[Satya] The problem is there is no "cure-all" timer value that will guarantee this behavior.
There was a ack based draft sometime back, but it would have introduced considerable overhead that caused complications.

Thanks,
Kishore

Thanks,
--Satya

---

From: John E Drake <[email-masked]>
Date: Tue, 24 Nov 2015 22:33:52 +0000

Satya,

Why is this better than having all of the nodes attached to a given ES wait for three seconds during which time all of the existing DF assignments remain in force?   I.e., what is wrong with the current behavior particularly since everything operates correctly during those three seconds?

Your draft is supposed to provide a clearer explanation of the current behavior, not to change it.  This is an example of mission creep and I think it is a mistake.

Yours Irrespectively,

John

From: BESS [mailto:[email-masked]] On Behalf Of Satya Mohanty (satyamoh)
Sent: Tuesday, November 24, 2015 5:12 PM
To: Kishore Tiruveedhula; Patrice Brissette (pbrisset); sudeep g ggg; [email-masked]
Subject: Re: [bess] REG: draft-mohanty-bess-evpn-df-election-02

Hi Kishore/Sudhin,

Thanks,
Kishore

Thanks,
--Satya

---

From: "sudeep g ggg" <[email-masked]>
Date: 25 Nov 2015 10:18:47 -0000

Hi Satya,

Let me thank you for your mail,it is much appreciated.You will take this in to account in next revision, much appreciated so that all will be in same page. One more thought though just a random thought.I would like to bring your kind attention.Since section 7.1 you clearly explains that you are not taking in to consideration about vlan mis configuration. My thought 
requires no answers from your side.But I would like to bring one case in to your frame of mind just sharing it.Once again big thank you for your reply.

Section 7.1

 Observe that currently the VLANs are derived from local configuration
and the FSM does not provide any protection against misconfiguration
where same EVI,ESI combination has different set of VLANs on
different participating PEs or one of the PEs elects to consider
VLANs as VLAN bundle and another as separate VLANs for election
purposes (service type mismatch).

for example PE1 loopback 150.1.1.1 PE2 loopback 150.1.2.2

PE1 has vlan 2,3,4 PE2 has vlan 3,4

so DF election at present V mod N so PE1 will be DF in PE1 calculation.
in PE2 DF calculation V mod N. PE2 will be DF. So in short both PE will be DF for a EVI.

Regards,
Sudhin Jacob

On Wed, 25 Nov 2015 03:42:00 +0530 "Satya Mohanty (satyamoh)"  wrote

Hi Kishore/Sudhin,

From: Kishore Tiruveedhula 

To: smohanty mohanty , "Patrice Brissette (pbrisset)" , sudeep g ggg ,
 "[email-masked]" 

Please see below inline…[Kishore].

[Kishore] Yes. The new PE need to wait for 3 seconds, but if new PE receives the type 4 route from the redundant PE before 3 seconds, the new PE can just move to DF immediately (if it becomes DF) just after receiving the type 4 without waiting for the
 3 seconds timer expiry because the otherredundant PE might have moved to Non-DF as there is no 3 seconds timer on the other PE which is moving from DF to Non-DF.
It is good idea to explicitly spell out this in this draft.

[Satya]Now, delay of BGP updates is not dependent on the above behavior. That depends on the network topology and queueing/processing at intermediate nodes.
With HRW, a PE coming up will result in minimal disruption of the established DF for various vlans (bundles) as opposed to RFC 7438 mod-based.

Thanks,
Kishore

Thanks,

--Satya

 
_______________________________________________

BESS mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/bess

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Wed, 25 Nov 2015 10:59:14 +0000

Hi Sudhin,

You may want to have a look at this draft:
https://tools.ietf.org/html/draft-rabadan-bess-evpn-ac-df-02

Provides a solution for your use-case in EVPN, without any control plane changes compared to RFC7432.
There are already implementations doing that.

Thanks.
Jorge

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of sudeep g ggg <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 25, 2015 at 11:18 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] REG: draft-mohanty-bess-evpn-df-election-02

Hi Satya,

Section 7.1

Regards,
Sudhin Jacob

Hi Kishore/Sudhin,

To: smohanty mohanty , "Patrice Brissette (pbrisset)" , sudeep g ggg ,
"[email-masked]<mailto:[email-masked]>"

Thanks,
Kishore

Thanks,

--Satya

BESS mailing list

[email-masked]<mailto:[email-masked]>

---

From: "sudeep g ggg" <[email-masked]>
Date: 25 Nov 2015 13:04:13 -0000

Hi Jorge,

Let me thank you for the mail. Since this mail thread is for one particular draft. I think it is good to open a new thread for discussing another draft. May I request you to give me some time to go through it and  I get back.I will open a new thread for discussing your draft.Appreciate your support.

Regards,
Sudhin Jacob

On Wed, 25 Nov 2015 16:29:29 +0530 "Rabadan, Jorge (Jorge)"  wrote

Hi Sudhin,

Thanks.
Jorge

To: "[email-masked]" 

Cc: "[email-masked]" , "[email-masked]" ,
 "[email-masked]" 

Hi Satya,

Let me thank you for your mail,it is much appreciated.You will take this in to account in next revision, much appreciated so that all will be in same page. One more thought though just a random thought.I would like to bring your kind attention.Since section
 7.1 you clearly explains that you are not taking in to consideration about vlan mis configuration. My thought

Section 7.1

Regards,

Sudhin Jacob

On Wed, 25 Nov 2015 03:42:00 +0530 "Satya Mohanty (satyamoh)" 
wrote

Hi Kishore/Sudhin,

To: smohanty mohanty , "Patrice Brissette (pbrisset)" 
, sudeep g ggg ,

"[email-masked]" 

Thanks,

Kishore

Thanks,

--Satya

BESS mailing list

[email-masked]

Get your own

FREE website, 
FREE domain & 

Know
 More >

 

BESS mailing list

[email-masked]