Subject: Re: [bess] Request for WG adoption of draft-mohanty-bess-evpn-df-election

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Fri, 10 Apr 2015 22:45:04 +0000

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-masked]> 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-masked]> 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-masked]" <[email-masked]>
>>Organization: Orange
>>Date: Friday, March 27, 2015 at 4:08 PM
>>To: Jorge Rabadan <[email-masked]>, Haoweiguo
>><[email-masked]>, "Satya Mohanty (satyamoh)" <[email-masked]>,
>>"[email-masked]" <[email-masked]>
>>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-masked]>
>>>> Date: Friday, March 27, 2015 at 9:00 AM
>>>> To: Jorge Rabadan <[email-masked]>, "Satya Mohanty
>>>> (satyamoh)" <[email-masked]>, "[email-masked]"
>>>> <[email-masked]>, "[email-masked]" <[email-masked]>
>>>> 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-masked]]
>>>>> Sent: Friday, March 27, 2015 23:39
>>>>> To: Haoweiguo; Satya Mohanty (satyamoh); [email-masked];
>>>>> [email-masked]
>>>>> 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-masked]>
>>>>> Date: Friday, March 27, 2015 at 8:11 AM
>>>>> To: Jorge Rabadan <[email-masked]>, "Satya Mohanty
>>>>> (satyamoh)" <[email-masked]>, "[email-masked]"
>>>>> <[email-masked]>, "[email-masked]" <[email-masked]>
>>>>> 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-masked]]
>>>>>> Sent: Friday, March 27, 2015 22:59
>>>>>> To: Haoweiguo; Satya Mohanty (satyamoh); [email-masked];
>>>>>> [email-masked]
>>>>>> 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-masked]>
>>>>>> Date: Friday, March 27, 2015 at 7:29 AM
>>>>>> To: Jorge Rabadan <[email-masked]>, "Satya Mohanty
>>>>>> (satyamoh)" <[email-masked]>, "[email-masked]"
>>>>>> <[email-masked]>, "[email-masked]" <[email-masked]>
>>>>>> 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-masked]]
>>>>>>> Sent: Friday, March 27, 2015 20:26
>>>>>>> To: Haoweiguo; Satya Mohanty (satyamoh); [email-masked];
>>>>>>> [email-masked]
>>>>>>> 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-masked]>
>>>>>>> Date: Thursday, March 26, 2015 at 9:55 PM
>>>>>>> To: "Satya Mohanty (satyamoh)" <[email-masked]>,
>>>>>>> "[email-masked]" <[email-masked]>,
>>>>>>>"[email-masked]"
>>>>>>> <[email-masked]>
>>>>>>> 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-masked]]
>>>>>>>> Sent: Friday, March 27, 2015 12:11
>>>>>>>> To: Haoweiguo; [email-masked]; [email-masked]
>>>>>>>> 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-masked]> wrote:
>>>>>>>>
>>>>>>>>> Hi Thomas,
>>>>>>>>> I know you are neutral, sorry for my reply vulnerable to be
>>>>>>>>> miunderstood.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> weiguo
>>>>>>>>>
>>>>>>>>> ________________________________________
>>>>>>>>> From: [email-masked] [[email-masked]]
>>>>>>>>> Sent: Friday, March 27, 2015 11:59
>>>>>>>>> To: Haoweiguo; [email-masked]
>>>>>>>>> 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-masked]]
>>>>>>>>>>> *Sent:* Thursday, March 26, 2015 6:17 PM
>>>>>>>>>>> *To:* John E Drake; Patrice Brissette (pbrisset)
>>>>>>>>>>> *Cc:* Ali Sajassi (sajassi); [email-masked]
>>>>>>>>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based
>>>>>>>>>>>on
>>>>>>>>>>> Paxos algorithm
>>>>>>>>>>>
>>>>>>>>>>> Pls see below.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> weiguo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 
>>>>>>>>>>>----------------------------------------------------------------
>>>>>>>>>>>-
>>>>>>>>>>>-
>>>>>>>>>>>--
>>>>>>>>>>> -
>>>>>>>>>>> -
>>>>>>>>>>> -
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> *From:*John E Drake [[email-masked]]
>>>>>>>>>>> *Sent:* Friday, March 27, 2015 6:00
>>>>>>>>>>> *To:* Haoweiguo; Patrice Brissette (pbrisset)
>>>>>>>>>>> *Cc:* Ali Sajassi (sajassi); [email-masked]
>>>>>>>>>>><mailto:[email-masked]>
>>>>>>>>>>> *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-masked]]
>>>>>>>>>>> *Sent:* Thursday, March 26, 2015 5:37 PM
>>>>>>>>>>> *To:* John E Drake; Patrice Brissette (pbrisset)
>>>>>>>>>>> *Cc:* Ali Sajassi (sajassi); [email-masked]
>>>>>>>>>>><mailto:[email-masked]>
>>>>>>>>>>> *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-masked]]
>>>>>>>>>>> *Sent:* Friday, March 27, 2015 4:41
>>>>>>>>>>> *To:* Haoweiguo; Patrice Brissette (pbrisset)
>>>>>>>>>>> *Cc:* Ali Sajassi (sajassi); [email-masked]
>>>>>>>>>>><mailto:[email-masked]>
>>>>>>>>>>> *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-masked]]
>>>>>>>>>>> *Sent:* Thursday, March 26, 2015 3:26 PM
>>>>>>>>>>> *To:* John E Drake; Patrice Brissette (pbrisset)
>>>>>>>>>>> *Cc:* Ali Sajassi (sajassi); [email-masked]
>>>>>>>>>>><mailto:[email-masked]>
>>>>>>>>>>> *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-masked]]
>>>>>>>>>>> *Sent:* Friday, March 27, 2015 1:28
>>>>>>>>>>> *To:* Patrice Brissette (pbrisset)
>>>>>>>>>>> *Cc:* Haoweiguo; Ali Sajassi (sajassi); [email-masked]
>>>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>>> *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-masked] <mailto:[email-masked]>> 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-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/>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>       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-masked]
>>>>>>>>>>> <mailto:[email-masked]>>
>>>>>>>>>>>       *Date: *Thursday, March 26, 2015 at 10:24 AM
>>>>>>>>>>>       *To: *Patrice Brissette <[email-masked]
>>>>>>>>>>>       <mailto:[email-masked]>>, John E Drake
>>>>>>>>>>><[email-masked]
>>>>>>>>>>>       <mailto:[email-masked]>>, Ali Sajassi
>>>>>>>>>>><[email-masked]
>>>>>>>>>>>       <mailto:[email-masked]>>, "[email-masked]
>>>>>>>>>>>       <mailto:[email-masked]>" <[email-masked]
>>>>>>>>>>><mailto:[email-masked]>>
>>>>>>>>>>>       *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-masked]
>>>>>>>>>>>           <mailto:[email-masked]>]
>>>>>>>>>>>           *Sent:* Thursday, March 26, 2015 20:54
>>>>>>>>>>>           *To:* Haoweiguo; John E Drake; Ali Sajassi (sajassi);
>>>>>>>>>>>           [email-masked] <mailto:[email-masked]>
>>>>>>>>>>>           *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-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/>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>           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-masked]
>>>>>>>>>>>           <mailto:[email-masked]>>
>>>>>>>>>>>           *Date: *Wednesday, March 25, 2015 at 10:38 PM
>>>>>>>>>>>           *To: *John E Drake <[email-masked]
>>>>>>>>>>>           <mailto:[email-masked]>>, Ali Sajassi
>>>>>>>>>>> <[email-masked]
>>>>>>>>>>>           <mailto:[email-masked]>>, "[email-masked]
>>>>>>>>>>>           <mailto:[email-masked]>" <[email-masked]
>>>>>>>>>>> <mailto:[email-masked]>>
>>>>>>>>>>>           *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-masked]
>>>>>>>>>>>               <mailto:[email-masked]>]
>>>>>>>>>>>               *Sent:* Thursday, March 26, 2015 7:16
>>>>>>>>>>>               *To:* Haoweiguo; Ali Sajassi (sajassi);
>>>>>>>>>>>[email-masked]
>>>>>>>>>>>               <mailto:[email-masked]>
>>>>>>>>>>>               *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-masked]] *On
>>>>>>>>>>>Behalf
>>>>>>>>>>> Of
>>>>>>>>>>>               *Haoweiguo
>>>>>>>>>>>               *Sent:* Wednesday, March 25, 2015 5:34 PM
>>>>>>>>>>>               *To:* Ali Sajassi (sajassi); [email-masked]
>>>>>>>>>>>               <mailto:[email-masked]>
>>>>>>>>>>>               *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-masked]
>>>>>>>>>>>               <mailto:[email-masked]>] on behalf of Ali
>>>>>>>>>>> Sajassi
>>>>>>>>>>>               (sajassi) [[email-masked]
>>>>>>>>>>> <mailto:[email-masked]>]
>>>>>>>>>>>               *Sent:* Thursday, March 26, 2015 0:21
>>>>>>>>>>>               *To:* [email-masked] <mailto:[email-masked]>
>>>>>>>>>>>               *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-masked]
>>>>>>>>>>> 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-masked]
>>>>>>>>>> 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-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>>>>> _______________________________________________
>>>>>>>> BESS mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>>>> _______________________________________________
>>>>>>> BESS mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>> _______________________________________________
>>>>> BESS mailing list
>>>>> [email-masked]
>>>>> 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-masked]
>https://www.ietf.org/mailman/listinfo/bess