Gentle Reminder to the chairs. Can we please initiate WG adoption? A fair amount of discussion has taken place and clarifications made.
Thanks, --Satya On 3/30/15 11:21 PM, "Satya Mohanty (satyamoh)" <[email protected]> wrote: >Hi, > >Given the interest and technical discussions on the topic of the EVPN DF >Election, and the favorable response of the community to the benefits of >the HRW scheme, I would like to request the WG to adopt >draft-mohanty-bess-evpn-df-election. > >Thanks to Jakob Heitz for presentation of slides at the IETF. > >Best regards, >--Satya > >On 3/27/15 8:52 PM, "Rabadan, Jorge (Jorge)" ><[email protected]> wrote: > >>Hi Thomas, >> >>You are right. >> >>Kishore, Weiguo and I were discussing face-to-face the scenario drawn by >>Weiguo below. And my conclusion is that there is no loop and there is >>nothing new that it was not discussed in this thread. EVPN single-active >>and split-horizon procedures take care of loops. If there are transient >>DF-DF periods, you can get some duplicate packets, but not infinite >>loops. >>And an implementation should allow a configurable timer that can be >>adjusted to the scale of the network so that the dual DF transient risk >>can be minimized or eliminated. >> >>About why all-active is not supported in the scenario below, I agree with >>your reasoning. RFC7432 only accepts LAG for all-active, since, >>otherwise, >>duplicate packets could be forwarded in normal state. >>draft-ietf-bess-dci-evpn-overlay-00 proposes an all-active MH network >>solution, but that is because EVPN runs in the access network too. >> >>Thanks. >>Jorge >> >>-----Original Message----- >>From: "[email protected]" <[email protected]> >>Organization: Orange >>Date: Friday, March 27, 2015 at 4:08 PM >>To: Jorge Rabadan <[email protected]>, Haoweiguo >><[email protected]>, "Satya Mohanty (satyamoh)" <[email protected]>, >>"[email protected]" <[email protected]> >>Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>algorithm >> >>>Hi Jorge, >>> >>>Jorge: >>>> If you have any other scenario, let’s talk offline. We are boring >>>>people >>>> ;-) >>> >>>I think its nice to keep the discussion on the list, which is here for a >>>reason (that is, not just for polls for adoption and WG last calls...). >>> >>>I'm sure these clarifications can be useful for some of the >>>participants, and the others can very much skip the thread. >>> >>>And there is, I think, perhaps one more thing worth spelling out. >>> >>>RFC7432 explains that for multi-homing in active-active mode, LAG is >>>required. >>>My understanding of the reason why, in this case, it is not supported to >>>connect the bridged >>>network via multiple CEs is that there is no technique to build a LAG >>>between two CEs and two PEs. >>> >>>Best, >>> >>>-Thomas >>> >>> >>> >>>Rabadan, Jorge : >>>> As I said: >>>> "Even if CE3 forwards to CE4->PE4, PE4 is NDF and will discard the >>>>frame. >>>> Remember MH network ES' as per your diagram below, only support >>>> single-active MH.” >>>> >>>> So there is NO LOOP. >>>> >>>> >>>> >>>> >>>> Thanks. >>>> Jorge >>>> >>>> -----Original Message----- >>>> From: Haoweiguo <[email protected]> >>>> Date: Friday, March 27, 2015 at 9:00 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, >>>>> The picture in email is just for a simplified explanation. Source MAC >>>>>can >>>>> be the layer 3 device connecting to CE3, CE3 will not drop the frame >>>>>so >>>>> easily. This is an absolutely loop. >>>>> >>>>> Thanks, >>>>> weiguo >>>>> >>>>> ________________________________________ >>>>> From: Rabadan, Jorge (Jorge) [[email protected]] >>>>> Sent: Friday, March 27, 2015 23:39 >>>>> 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, >>>>> >>>>> I disagree with your explanation below. >>>>> >>>>> This is the flow assuming PE1-PE2 *might* be both DF and PE3 is DF: >>>>> >>>>> CE3--->PE3------>PE2--->CE2---->CE1---->PE1---->PE3-->CE3――>DROP >>>>> >>>>> If the MAC SA of the frame is CE3’s MAC, CE3 will discard. >>>>> Even if CE3 forwards to CE4->PE4, PE4 is NDF and will discard the >>>>>frame. >>>>> Remember MH network ES' as per your diagram below, only support >>>>> single-active MH. >>>>> >>>>> >>>>> Thanks. >>>>> Jorge >>>>> >>>>> -----Original Message----- >>>>> From: Haoweiguo <[email protected]> >>>>> Date: Friday, March 27, 2015 at 8:11 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, >>>>>> 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--->PE >>>>>>4 >>>>>>- >>>>>>-- >>>>>> - >>>>>>> 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 >>>>>>>>>>>t >>>>>>>>>>>m >>>>>>>>>>>l> >>>>>>>>>>> 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 >>>>>>>>>>>t >>>>>>>>>>>m >>>>>>>>>>>l> >>>>>>>>>>> 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-segmen >>>>>>>>>>>t >>>>>>>>>>>- >>>>>>>>>>>ro >>>>>>>>>>> u >>>>>>>>>>> t >>>>>>>>>>> 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. >>>>>>>>> _______________________________________________ >>>>>>>>> BESS mailing list >>>>>>>>> [email protected] >>>>>>>>> https://www.ietf.org/mailman/listinfo/bess >>>>>>>> _______________________________________________ >>>>>>>> BESS mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/bess >>>>>>> _______________________________________________ >>>>>>> BESS mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/bess >>>>> _______________________________________________ >>>>> 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 _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
