There's no loop. Any BUM packet received from either CE1 or CE2 will not be forwarded back to them because of the ES label.
Yours Irrespectively, John > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Haoweiguo > Sent: Friday, March 27, 2015 10:30 AM > To: Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT - > [email protected]; [email protected] > Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos > algorithm > > Hi Jorge, > 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.ht > ml> > >>>> 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.ht > ml> > >>>> for Company Registration Information. > >>>> > >>>> > >>>> *From: *Haoweiguo <[email protected] > >>>> <mailto:[email protected]>> > >>>> *Date: *Wednesday, March 25, 2015 at 10:38 PM > >>>> *To: *John E Drake <[email protected] > >>>> <mailto:[email protected]>>, Ali Sajassi <[email protected] > >>>> <mailto:[email protected]>>, "[email protected] > >>>> <mailto:[email protected]>" <[email protected] > >>>><mailto:[email protected]>> > >>>> *Subject: *Re: [bess] Handshaking among PEs in an EVPN ES > >>>> based on Paxos algorithm > >>>> > >>>> Hi John, > >>>> > >>>> Firstly i think EVPN community should reach consensus on > >>>> the issues of current DF election mechanism. All these > >>>> issues should be resolved in a single new DF election > >>>> draft,rather than in multiple separate drafts. If your > >>>> draft can solve all these issues and stable, i have no > >>>> question for its progressing. But if your draft have not > >>>> solved all issues, i think it had better combine with > >>>> other drafts to provide a comprehensive solution. I think > >>>> the issues listed in draft-rabadan-bess-evpn-ac-df-01 and > >>>> draft-hao-bess-evpn-df-handshaking-00 is valid, it should > >>>> be resolved. So i think although your new Hash algorithm > >>>> for DF election is good, it only includes partial > >>>> enhancements, maybe it still needs some time for > >>>>consensus. > >>>> > >>>> Thanks, > >>>> > >>>> weiguo > >>>> > >>>> > >>>>-------------------------------------------------------------------- > >>>>--- > >>>>- > >>>> > >>>> *From:*John E Drake [[email protected] > >>>> <mailto:[email protected]>] > >>>> *Sent:* Thursday, March 26, 2015 7:16 > >>>> *To:* Haoweiguo; Ali Sajassi (sajassi); [email protected] > >>>> <mailto:[email protected]> > >>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES > >>>> based on Paxos algorithm > >>>> > >>>> Weiguo, > >>>> > >>>> Your proposal introduces a control plane processing load > >>>> that is O(#EVIs * PEs) per DF election and given that > >>>> there can be 4K EVIs per ES, this looks like a > >>>> **substantial** load. Furthermore, > >>>> > >>>> you can¹t use the ES route to co-ordinate DF election > >>>> because you would need to carry your new extended > >>>> community for each EVI and they would not all fit. You > >>>> also can¹t use the Per EVI Ethernet AD route because that > >>>> is processed by all PEs in the EVI. > >>>> > >>>> I think that from a practical perspective the new DF > >>>> election proposed in Satya¹s draft is sufficiently stable > >>>> that it renders your draft moot, even if it could be made > >>>> to work. > >>>> > >>>> Yours Irrespectively, > >>>> > >>>> John > >>>> > >>>> *From:*BESS [mailto:[email protected]] *On Behalf Of > >>>> *Haoweiguo > >>>> *Sent:* Wednesday, March 25, 2015 5:34 PM > >>>> *To:* Ali Sajassi (sajassi); [email protected] > >>>> <mailto:[email protected]> > >>>> *Subject:* Re: [bess] Handshaking among PEs in an EVPN ES > >>>> based on Paxos algorithm > >>>> > >>>> Hi Ali, > >>>> > >>>> Thanks for your information. I scanned through this > >>>>draft, > >>>> it really introduces inter-chassis message for DF > >>>>election > >>>> handshaking, the requirements in this draft is to > >>>> eliminate transiet Loop and traffic duplication. Current > >>>> EVPN DF election mechanism already eliminated loop and > >>>> traffic duplication by configuring long reception > >>>>timer on > >>>> each multi-homed PE, but up to reception timer traffic > >>>> disruption issue still exist. EVPN for DCI is an > >>>>important > >>>> use case for EVPN, up to reception timer traffic > >>>> disruption can't be tolerated for service providers, it > >>>> should be improved. > >>>> > >>>> Also for accuracy, i think handshaking state machine on > >>>> each multi-homed PE is also needed. From solution > >>>> perspective, in my draft, no inter-chassis message is > >>>> introduced, only one new extended community is > >>>>introduced, > >>>> i think the process is comparatively simple than your > >>>> following draft. > >>>> > >>>> Current EVPN DF election has some drawbacks, so there are > >>>> three new drafts about DF election emerged. I think BESS > >>>> WG can consider these three drafts in global view, a > >>>> single,comprehensive new DF election draft is hoped. > >>>> > >>>> thanks. > >>>> > >>>> Thanks, > >>>> > >>>> weiguo > >>>> > >>>> > >>>>-------------------------------------------------------------------- > >>>>--- > >>>>- > >>>> > >>>> *From:*BESS [[email protected] > >>>> <mailto:[email protected]>] on behalf of Ali Sajassi > >>>> (sajassi) [[email protected] <mailto:[email protected]>] > >>>> *Sent:* Thursday, March 26, 2015 0:21 > >>>> *To:* [email protected] <mailto:[email protected]> > >>>> *Subject:* [bess] Handshaking among PEs in an EVPN ES > >>>> based on Paxos algorithm > >>>> > >>>> FYI- First published July 4, 2011 > >>>> > >>>> > >>>>https://datatracker.ietf.org/doc/draft-sajassi-l2vpn-evpn-segment-ro > >>>>ute > >>>>/ > >>>> > >>>> -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
