Robert, I think Aijun is saying the same thing as you. Aijun/co-authors, could you please share the diff with the changes so Robert can confirm?
I hope it helps us converge. Thanks, Ketan On Wed, 11 Feb, 2026, 3:18 pm Robert Raszuk, <[email protected]> wrote: > Hi Aijun, > > For this draft you really do not need to use ORF PERMIT at all. Just > remove it and we are done. There is not a single use case in the draft > which would prove that ORF PERMIT is needed to be supported. > > Thx, > R. > > On Wed, Feb 11, 2026 at 10:42 AM Aijun Wang <[email protected]> > wrote: > >> Hi, Ketan: >> >> >> >> [make "permit all" as the default behavior unless prevented by an ORF >> Entry with DENY.] is more simpler than letting the VPN Prefix ORF >> originator send one “permit all” entry. >> >> >> >> If you all agree, we can add some descriptions on the behavior of the VPN >> Prefix ORF receiver in next version, and also the sender’s behavior(not >> sending such default entry then). >> >> >> >> Aijun >> >> >> >> *From:* [email protected] [mailto:[email protected]] >> *On Behalf Of *Ketan Talaulikar >> *Sent:* Wednesday, February 11, 2026 4:03 PM >> *To:* Wei Wang <[email protected]> >> *Cc:* Robert Raszuk <[email protected]>; BESS <[email protected]>; idr < >> [email protected]>; Susan Hares <[email protected]>; Keyur Patel < >> [email protected]> >> *Subject:* [Idr] Re: [bess] Re: Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 >> Week WGLC onchanges (1/29/2026 to 1/5/2026) >> >> >> >> Hi Wei, >> >> >> >> Since the goal of this new ORF type is to filter out specific VPN routes >> and this ORF mechanism is not really like an ACL (an arbitrary order of >> permit and deny action rules), perhaps the simpler option would be remove >> the use of PERMIT and make "permit all" as the default behavior unless >> prevented by an ORF Entry with DENY. >> >> >> >> I believe this is the simpler option that Robert is suggesting. Is this >> something that you could consider? >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> On Wed, Feb 11, 2026 at 1:25 PM Wei Wang <[email protected]> wrote: >> >> Hi Ketan and Robert, >> >> >> >> I think Ketan got the point. >> >> In order to make the doument more clearly, we would like to add the >> following description in section 5.1: >> >> >> >> "The default entry is a special entry where the value of the "Overload >> VPN routes process method" is not applicable." >> >> >> >> The operations ADD, REMOVE, and REMOVE-ALL can be applied to the default >> entry. >> >> >> >> Best Regards, >> >> Wei >> >> >> >> Original >> ------------------------------ >> >> From: Robert Raszuk <[email protected]> >> >> Date: 2026-02-10 21:37 >> >> To: Ketan Talaulikar <[email protected]> >> >> Cc: Wei Wang <[email protected]>, BESS <[email protected]>, idr < >> [email protected]>, Susan Hares <[email protected]>, Keyur Patel < >> [email protected]> >> >> Subject: Re: [bess] Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 >> Week WGLC onchanges (1/29/2026 to 1/5/2026) >> >> >> >> Hi Ketan, >> >> >> >> I decoded what draft defines in section 5.2 as procedure when handling >> PERMIT ORF Message: >> >> >> >> So that literally translates to: >> >> >> >> *If ORF Match filter is set to PERMIT * >> >> *AND * >> >> *If Overload = 0 which means ALL VPN ROUTES matching the filter MUST BE >> WITHDRAWN * >> >> *AND * >> >> *if Seq=0xFFFFFFFF (so this MUST be last ORF entry)* >> >> *AND * >> >> *if length=8 (so there must not be any optional TLVs) * >> >> *AND * >> >> *if RD=0 (meaning apply to all VPN prefixes for a given AFI/SAFI)* >> >> *then * >> >> *INSTALL the entry. * >> >> >> >> The first contradiction in the definition is based on the use of PERMIT >> with logical AND to Overload = 0 definition which is stated to mean ALL VPN >> ROUTES matching the filter *MUST BE WITHDRAWN* .. and here filter is >> RD=0 meaning MATCH ALL. >> >> >> >> I think authors think that they must address PERMIT even if it does not >> deliver any value to the draft. I am simply saying not to allow PERMIT in >> their ORF definition at all. Just use DENY what their draft is all about. >> >> >> >> In the ORF world PERMIT means to advertise only those routes which match >> a filter ... so if they like to go by RD it MUST not be 0. But again IMO >> attracting the routes is not what authors claim as the value of the draft. >> >> >> >> Kind regards, >> >> Robert >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Feb 10, 2026 at 2:28 PM Ketan Talaulikar <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Wei, >> >> >> >> Thanks for the updated version - it addresses the comments that I had >> raised. >> >> >> >> Coming to Robert's concern with the use of PERMIT, I would like to share >> my understanding to cross-check if I have made a mistake in my reading. >> >> >> >> The only ORF entry with PERMIT allowed is the "last" catch-all entry that >> says to permit everything that has not been denied by previous (DENY) >> rules. If such an entry is always required, then I found the use of the >> SHOULD to give a conflicting meaning. >> >> >> >> Besides the above, any other ORF entry with PERMIT MUST be discarded. So, >> everything else is about denying/filtering out matching routes and the >> operations are ADD, REMOVE or REMOVE ALL for those rules. >> >> >> >> But the ADD/REMOVE/REMOVE-ALL should also apply to the "default" PERMIT >> rule as well? >> >> >> >> Robert, I am not sure if I've understood your point correctly, and please >> correct me if I'm wrong. >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> On Tue, Feb 10, 2026 at 2:44 PM Robert Raszuk <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Wei, >> >> >> >> You missed the most important comment. As currently defined, use of ORF >> PERMIT is self contradicting. Version -27 still has the bad text in section >> 5.2. >> >> >> >> My recommendation is to either remove use of ORF PERMIT from your >> proposal (easy edit and you are not using it really for anything useful) or >> fix it and use PERMIT correctly which will require a lot of work and text >> to be added to the draft. >> >> >> >> Kind regards, >> >> Robert >> >> >> >> >> >> >> >> On Tue, Feb 10, 2026 at 9:05 AM Wei Wang <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Ketan and Robert, >> >> >> >> Thanks for your comments and suggestions! We have uploaded the -v27 to >> address your comments. >> (*https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-27 >> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-27>* >> ) >> >> And please also see the in-line replies. >> >> >> >> Best Regards, >> >> Wei >> >> Original >> ------------------------------ >> >> From: Robert Raszuk <*[email protected] <[email protected]>*> >> >> Date: 2026-02-06 17:55 >> >> To: Ketan Talaulikar <*[email protected] <[email protected]>*> >> >> Cc: Wei Wang <*[email protected] <[email protected]>*>, BESS >> <*[email protected] >> <[email protected]>*>, idr <*[email protected] <[email protected]>*>, Susan Hares >> <*[email protected] >> <[email protected]>*>, Keyur Patel <*[email protected] <[email protected]>*> >> >> Subject: [bess] Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week >> WG LC onchanges (1/29/2026 to 1/5/2026) >> >> >> >> Hi, >> >> >> >> Thank you for posting version -26 of this document. >> >> >> >> I see that you still did not want to make sending RD optional. Oh well I >> do believe making it as optional TLV would make this extension more >> practical and much more useful. And the most interesting point is >> that functionality wise you still support the case of RD = 0 (meaning >> irrespective of RD value) apply the filter. >> >> >> >> So instead of sending 8 octets of 0 you could just not send it at all. >> >> *[WW]: We still hope to keep the "RD" in the "VPN Prefix ORF >> type-specific encoding", becasue the key point of VPN Prefix ORF mechanism >> is to identify the source of overwhelmed VPN routes:* >> >> *1) In scenario that is unique RD per PE, RD soely can identify the >> source of overwhelmed VPN routes correctly* >> >> *2) In scenario that is unique RD per VPN, RD + Source PE can identify >> such source.* >> >> >> >> *Anyway, carrying RD can control the advertisements of VPN routes in more >> granular manner.* >> >> >> >> >> >> Please see some more review comments ... >> >> >> >> 1) >> >> >> >> Why do both figures have identical descriptions yet showing different >> pictures ? >> >> >> >> Figure 1: VPN Prefix ORF type-specific encoding >> >> Figure 2: VPN Prefix ORF type-specific encoding >> >> >> >> I guess it should be instead: >> >> >> >> Figure 1: VPN Prefix ORF common part encoding >> >> Figure 2: VPN Prefix ORF type-specific encoding >> >> *[WW]: You're correct. This typo is modifiedI in -v27.* >> >> >> >> 2) >> >> >> >> In section 5.2 I am finding extremely hard to parse description regarding >> using match filters with PERMIT. >> >> >> >> Quote: >> >> >> >> If the "Match" bit is "PERMIT", and is the "default" entry (the >> overload VPN routes process method equal to 0, sequence equal to >> 0xFFFFFFFF, length is equal to 8, and Route Distinguisher is equal to >> 0), the entry SHOULD be installed. Otherwise, if the "Match" bit is >> "PERMIT", the entry MUST be discarded and a warning MUST be sent to >> the operator. >> >> >> >> So that literally translates to: >> >> >> >> *If ORF Match filter is set to PERMIT * >> >> *AND * >> >> *If Overload = 0 which means ALL VPN ROUTES matching the filter MUST BE >> WITHDRAWN * >> >> *AND * >> >> *if Seq=0xFFFFFFFF (so this MUST be last ORF entry)* >> >> *AND * >> >> *if length=8 (so there must not be any optional TLVs) * >> >> *AND * >> >> *if RD=0 (meaning apply to all VPN prefixes for a given AFI/SAFI)* >> >> *then * >> >> *INSTALL the entry. * >> >> >> >> This is so confusing ... and semantically incorrect. >> >> >> >> First PERMIT must not mean WITHDRAW - this is contradicting the intention >> to use PERMIT filters ... Please see reasons for PERMIT vs DENY is >> described in RFC5291: >> >> >> >> The "Match" component is used to support matching granularity on a >> per ORF entry basis. It can be either PERMIT or DENY. The semantics >> of PERMIT is to ask the peer to pass updates for the set of routes >> that match the ORF entry. The semantics of DENY is to ask the peer >> not to pass updates for the set of routes that match the ORF entry. >> >> >> >> then >> >> >> >> Sending RD = 0 makes sense only with some optional TLVs which the above >> prohibits to send along with PERMIT. >> >> >> >> So bottom line you have not defined the use of PERMIT correctly. Perhaps >> you can just say black on white that you are not supporting PERMIT ORF >> filters at all in your specification. >> >> *[WW]: Thank you to point out it. I think we can remove "the overload VPN >> routes process method equal to 0".* >> >> >> >> Thx, >> >> Robert >> >> >> >> On Thu, Feb 5, 2026 at 7:06 AM Ketan Talaulikar <*[email protected] >> <[email protected]>*> wrote: >> >> Hello Authors, >> >> >> >> I see that you have just posted v26 - >> *https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-26 >> <https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-26>* >> >> >> >> There are some issues in the table below (similar in the text as well) >> and some suggestions: >> >> >> >> +-----------+-------------------------+ >> >> | AFI | SAFI | >> >> +-----------+-------------------------+ >> >> |IPv4/IPv6 |MCAST-VPN | >> >> | |MCAST-VPLS | >> >> | |VPLS | >> >> | |BGP EVPNs | >> >> | |MPLS-labeled VPN address | >> >> +-----------+-------------------------+ >> >> |L2VPN |BGP EVPNs | >> >> +-----------+-------------------------+ >> >> >> >> Please give this table a number. Would be good to specifically list the >> AFI and SAFI values here for clarity and give a reference to their base >> RFCs. >> >> *[WW]: OK. These is added in -v27.* >> >> >> >> Most importantly, I was not aware of IPv4/IPv6 AFI being used with either >> VPLS or EVPN SAFIs. Can you please provide a reference? >> >> *[WW]: After double checking, the VPLS, EVPN and MCAST-VPLS SAFIs should >> be used with L2VPN. This is changed in -v27. * >> >> >> >> Also, I see that you have introduced a filter TLV for Route Types for >> EVPN. A similar problem exists for other types of VPNs having typed NLRIs >> as pointed out by Robert. Isn't a similar mechanism required for those >> address families? Therefore, shouldn't this mechanism be generic to VPNs >> with typed NLRIs? >> >> *[WW]: Yes, I think this TLV can be used for others routes that carry the >> Route type field. So we remove the description stating that this TLV is >> restricted to EVPN routes.* >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> On Wed, Feb 4, 2026 at 12:54 PM Wei Wang <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Robert, >> >> >> >> I think a "EVPN Route Type TLV" can be added in Section 4 to control the >> filter of EVPN routes. >> >> >> >> Best Regards, >> >> Wei >> >> >> >> Original >> ------------------------------ >> >> From: Robert Raszuk <*[email protected] <[email protected]>*> >> >> Date: 2026-02-03 17:47 >> >> To: Wei Wang <*[email protected] <[email protected]>*> >> >> Cc: Ketan Talaulikar <*[email protected] <[email protected]>*>, >> BESS <*[email protected] <[email protected]>*>, idr <*[email protected] >> <[email protected]>*>, Susan Hares <*[email protected] <[email protected]>*>, Keyur >> Patel <*[email protected] <[email protected]>*> >> >> Subject: Re: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC >> onchanges (1/29/2026 to 1/5/2026) >> >> >> >> Hi Wei, >> >> >> >> Ad 2 - You can not if you have a single interface from the customer. >> >> >> >> Ad 3 - It would be an optional TLV of course. but providing required >> control. >> >> >> >> Ad 4 - I am not sure if private development counts as an implementation >> for the purposes of IDR document progression. But I will refer to chairs >> and AD to judge on that. >> >> >> >> Cheers, >> >> R. >> >> >> >> On Tue, Feb 3, 2026 at 3:21 AM Wei Wang <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Ketan and Robert, >> >> >> >> 1. If all the types of EVPN routes are under one VRF and there is no >> threshold control mechanism for each of these types, we can only treat them >> >> all together, although some of them may be more importnace than >> others. >> >> >> >> 2. If we want to control these EVPN routes seperately, we can put them >> into different VRFs, via the configuration of RTs of each VRF, then the >> mechanism that is described in this document can apply and needs not be any >> changed. >> >> >> >> 3. We also think that add route types within the encoding is not >> practical, because other NLRI types don't have the "route type" field. >> >> >> >> 4. The implementations of this draft has been done via FRR, but we >> haven't committed it. >> >> >> >> >> >> Best Regards, >> >> Wei >> >> >> >> Original >> ------------------------------ >> >> From: Ketan Talaulikar <*[email protected] <[email protected]>*> >> >> Date: 2026-01-30 22:44 >> >> To: BESS <*[email protected] <[email protected]>*> >> >> Cc: idr <*[email protected] <[email protected]>*>, Robert Raszuk <*[email protected] >> <[email protected]>*>, Susan Hares <*[email protected] <[email protected]>*>, >> Keyur Patel <*[email protected] <[email protected]>*> >> >> Subject: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC on >> changes (1/29/2026 to 1/5/2026) >> >> >> >> I concur with Robert. >> >> >> >> This mechanism introduces a mandatory RD filter. I won't get into the >> debate of the operational value and efficacy of this mechanism - that is >> for operators to report on. I don't see a technical issue with L3VPN. >> >> >> >> The same cannot be said about EVPN (and I have not yet considered the >> expanded applicability proposed by the authors to MVPN and VPLS). >> >> >> >> Let me elaborate on the issue with using this with EVPN. >> >> - The goal of this mechanism is to prevent overload of VPN routes from a >> specific PE+VPN-context >> >> - The primary and mandatory filter is the RD (there are others but they >> supplement RD) >> >> - Let's say there is an overload of MAC+IP routes and this mechanism >> kicks in. Would that affect the AD per ES route with the same RD? What >> would be its implication? >> >> >> >> The question is how this would affect/impact different types of EVPN >> route types given its primary RD filter? >> >> >> >> May I request someone from the BESS WG to review this specific aspect >> (broader review is also welcome!) : >> *https://www.ietf.org/archive/id/draft-ietf-idr-vpn-prefix-orf-25.html >> <https://www.ietf.org/archive/id/draft-ietf-idr-vpn-prefix-orf-25.html>* >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> On Fri, Jan 30, 2026 at 7:20 PM Robert Raszuk <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Aijun, >> >> >> >> On Fri, Jan 30, 2026 at 2:37 PM Aijun Wang <*[email protected] >> <[email protected]>*> wrote: >> >> Hi, Robert: >> >> >> >> The document doesn’t filter the VPN prefixes solely based on RD, it bases >> mainly the RT and other additional TLVs. >> >> RD is only one additional parameter that can be used to assist the filter >> of the overflow VPN prefixes routes. >> >> >> >> The way the draft is written it is actually the other way around. Other >> optional parameters may augment RD based filtering. >> >> >> >> See this: >> >> >> >> Optional TLVs: Carries potential additional information to provide >> extensibility for the VPN Prefix ORF mechanism. Its format is >> shown in Figure 6. >> >> >> >> Btw there is no "Figure 6" :). >> >> >> >> And as we all know all other "optional parameters" can also be sent today >> with other mechanisms for filtering routes. >> >> >> >> Thx, >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> On Jan 30, 2026, at 19:36, Robert Raszuk <*[email protected] >> <[email protected]>*> wrote: >> >> >> >> Dear Wei and WG, >> >> >> >> Ad 1 - Nope this does not address my comment as you still can not >> distinguish with current encoding of your draft to which NLRI types given >> RD applies. So as of today it is not applicable to any AFI/SAFIs with typed >> NLRIs (specifically to EVPNs). >> >> >> >> Ad 2 - ok. >> >> >> >> Ad 3 - I have a different opinion. >> >> >> >> But rereading your document there is one more fundamentally incorrect >> section: >> >> >> >> >> >> >> >> *3.2. Address Prefix ORF Using Address Prefix ORF to filter VPN routes >> requires a pre- configuration, but it is impossible to know in advance >> which prefix may exceed the predefined threshold.* >> >> >> >> Please note that RD is part of the prefix. The above comment in section >> 3.2 is wrong as it neglects the fact that prefix ORF contains a length >> field. So Address Prefix ORF as defined in RFC5292 when used *with the >> length of 64* is exactly RD based ORF. In fact it is even more flexible >> as subject doc if you use Minlen and Maxlen fields correctly :). >> >> >> >> So using plain vanilla RFC5292 which is already implemented and shipping >> completely removes the need to progress the subject document any further. I >> don't understand why we are last calling something which has already been >> standardized and in general form published as RFC in 2008. >> >> >> >> Kind regards, >> >> Robert >> >> >> >> On Fri, Jan 30, 2026 at 3:54 AM Wei Wang <*[email protected] >> <[email protected]>*> wrote: >> >> Hi Robert, >> >> >> >> Thanks for your comments. And please see my in-line replies. If these >> modifications can address your concerns, we will update this draft based on >> them. >> >> >> >> Best Regards, >> >> Wei >> >> >> >> Original >> ------------------------------ >> >> From: Robert Raszuk <*[email protected] <[email protected]>*> >> >> Date: 2026-01-30 02:06 >> >> To: Susan Hares <*[email protected] <[email protected]>*> >> >> Cc: idr <*[email protected] <[email protected]>*>, Keyur Patel <*[email protected] >> <[email protected]>*> >> >> Subject: [Idr] Re: draft-ietf-idr-vpn-prefix-orf-25 - 1 Week WG LC on >> changes (1/29/2026 to 1/5/2026) >> >> >> >> Dear WG, >> >> >> >> As recommended moving my three comments to this thread: >> >> >> >> 1) >> >> > KT> My point was that simply filtering on the RD can accidentally >> affect Route Types 1 >> > (as an example) and have severe implications on EVPN services. This is >> not an issue >> > with CP-ORF but specific to this new mechanism. Please consider at >> least warning >> > about this? >> >> IMO warning is not enough. >> >> I would rather either suggest extending the encoding to cover AFI/SAFIs >> with typed NLRIs or make the clear statement that this draft is not >> applicable to AFI/SAFIs with typed NLRIs at all. >> >> *[WW]: We can add a table about the AFI and SAFI types applicable to this >> mechanism in Section 4 as follow:* >> >> >> >> *+-------+-------------------------------+* >> >> *| AFI | SAFI |* >> >> *+-------+-------------------------------+* >> >> *|IPv4/ |MCAST-VPN |* >> >> *|IPv6 |MCAST-VPLS |* >> >> *| |VPLS |* >> >> *| |BGP EVPNs |* >> >> *| |MPLS-labeled VPN address |* >> >> *+------+--------------------------------+* >> >> *|L2VPN |BGP EVPNs |* >> >> *+------+--------------------------------+* >> >> 2) >> >> Also I think there is typo in this sentence: >> >> However, each existing solution has its own limitation as described in >> Section 4. >> it should be >> However, each existing solution has its own limitation as described in >> Section 3. >> >> *[WW] Thank you! We will modify it in the updated version.* >> >> 3) >> >> >> >> I would also like to see in this specification a clear note or section >> stating that this document violates Proposed Standard RFC4364 as RFC4364 >> clearly defines in section 4.1 what RD is all about: >> >> >> >> >> >> >> >> >> * An RD is simply a number, and it does not contain any inherent >> information; it does not identify the origin of the route or the set of >> VPNs to which the route is to be distributed. The purpose of the RD is >> solely to allow one to create distinct routes to a common IPv4 address >> prefix. Other means are used to determine where to redistribute the >> route (see Section 4.3).* >> >> >> >> RD should never be used for import, export or any sort of filtering and >> it's sole role is to make prefixes unique. >> >> *[WW]: I think the usage of RD in this document doesn't conflict with the >> description in RFC4364. RD is just a distinguisher carried by VPN routers. >> It is a part of VPN Prefix. We just use this distinguisher to filter the >> VPN routes. It is simliar with that we do the prefixes filter via the >> shorter, common part of the related prefixes.* >> >> >> >> Kind regards, >> >> Robert >> >> >> >> >> >> On Thu, Jan 29, 2026 at 2:41 PM Susan Hares <*[email protected] >> <[email protected]>*> wrote: >> >> Greetings: >> >> >> >> draft-ietf-idr-vpn-prefix-orf-25 has made changes during the AD review. >> >> >> >> This begins a 1-week WG last call on the changes. >> >> If you have concerns regarding the changes, please respond to this >> message. >> >> >> >> If no concerns or objections are raised, this document will enter into >> IETF LC. >> >> >> >> Cheerily, IDR Chairs >> >> [Sue for Keyur Patel (shepherd) >> >> >> >> >> >> >> >> _______________________________________________ >> Idr mailing list -- *[email protected] <[email protected]>* >> To unsubscribe send an email to *[email protected] <[email protected]>* >> >> >> >> _______________________________________________ >> Idr mailing list -- *[email protected] <[email protected]>* >> To unsubscribe send an email to *[email protected] <[email protected]>* >> >> _______________________________________________ >> Idr mailing list -- *[email protected] <[email protected]>* >> To unsubscribe send an email to *[email protected] <[email protected]>* >> >> >> >> >> >> _______________________________________________ >> Idr mailing list -- *[email protected] <[email protected]>* >> To unsubscribe send an email to *[email protected] <[email protected]>* >> >> >> >> >> >>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
