Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB9F120113 for ; Fri, 10 May 2019 01:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52q_ryAQNbmA for ; Fri, 10 May 2019 01:40:56 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1779D1201D7 for ; Fri, 10 May 2019 01:40:56 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id o7so5700197qtp.4 for ; Fri, 10 May 2019 01:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F2pQ1omsPRzTS91eu+l/M6BVKYAZhMeHFcUhSHapcwA=; b=LTFXfd1lVdUpsftiRScX+xLpkXlvL6N8ZtD6QutXhgFvmefs9YF9N11qonBVQmswnC yqUFVwDnLcHVtqR8cK4TqSS1IwDXQzDC28uWKeBe9ISl44AmmeF9eoiCeVCfinVCD/hA 6dPB/wbzRvh9oQKIakAnjHOTec0W5vnNgz6QDFHLiM9lS0SWm3jRfFTrGSbr3E7zx5g0 QF1K5nhBqvsmxn7C6V3RFU9t8qKOIzgfFZuqynZlbjJ+305wkXRAHtkZhUf3vLmI15B7 hSDs4ZfkiU55ghQNEALEFcbnEJfqU2DytE1Cw2bMVTRzpoesfCsTXLGZFSB7ZvHkMFhB T53w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F2pQ1omsPRzTS91eu+l/M6BVKYAZhMeHFcUhSHapcwA=; b=i9OE4HvZFWFzf8mZewfkzVY+5d0KeoOBW1rIl/f12oxCfeSmoEhoH8ubYMMvFKNsg6 9iSO90pM2z8cD+WPHaWYDb3OsaKxAXz793pARZnUHB9YXOnUmyNa/iWJF0UjgKPeyRl+ IhV9oKFx8K62g4tO4wIEvzvJNfpQYq12yhxsJJFSIO31/Ny6Kq8+he3Yh9uVjemyZ1LY sS60bYFmaemRlizryHlZYeK5UMZQ/de1Y4fc8qs7y1Jhj8fwwXl5fNjjmYQ0acLnhp6K 50Vxc/xU9O4YvytMAjs9CBzL7SZV5XqrG7JMtOVddWRVLmLZGl36VccmFuY68IqVKdHj iNNw== X-Gm-Message-State: APjAAAXwoy+HXyXVhy06uA3iXo74ymULoME7w/EKvgzLCHkShakAKmxY uEQnvhJyUDzlvCgLSZivXqMBlhQIEHzBM9+SfqgGEw== X-Google-Smtp-Source: APXvYqxXASZnnfWPHpZOgxufynE8w5vNaZE0v7L/prqgmn8dnUl+JbnOOhpXuVDCUtymVXJPL60UGzDcVZfTA6kj/UY= X-Received: by 2002:ac8:2899:: with SMTP id i25mr8371331qti.361.1557477655027; Fri, 10 May 2019 01:40:55 -0700 (PDT) MIME-Version: 1.0 References: <45903917-F08E-47ED-BCA0-46530D63ED16@tix.at> <1355fad118884baaa5ee6a15ea865179@turkcell.com.tr> In-Reply-To: <1355fad118884baaa5ee6a15ea865179@turkcell.com.tr> From: Robert Raszuk Date: Fri, 10 May 2019 10:40:43 +0200 Message-ID: To: ERCIN TORUN Cc: Christoph Loibl , "Jakob Heitz (jheitz)" , "idr@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005fb67f058884866e" Archived-At: Subject: Re: [Idr] update proposal to draft-ietf-idr-rfc5575bis-14 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 08:41:01 -0000 --0000000000005fb67f058884866e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thx for clarification. So your use case is to use BGP as targeted config push. You seems not worried that 600+ routers and RRs will get FS updates only for 599+ to drop them. I do think that BGP should *not* be used for config push regardless if this is ACLs or SIDs or XYZ. The idea of original 5575 leverages BGP for real p2mp filter push and that along with unicast validation are the only two reasons why we used BGP for it to start with. In your use case neither of those two reasons apply Cheers, R. On Fri, May 10, 2019 at 9:22 AM ERCIN TORUN wrote: > Hello Christoph, Jakob, Robert, > > > > We wanted to filter DDOS attacks happening inside our AS , attacks from > customers to customers, so my idea is not related to MPLS VPN or filterin= g > a DDOS attack coming from a transit provider. Customers layer3 connection= s > are terminated on around 600 routers today, which will increase when we > push down layer3 terminations further into the edge. > > > > As Christoph mentioned solution eases the configuration by taking out > manual configuration (assuming a DDOS analyzer could analyze the origin > interface/router of the attack and insert BGP router id into FS routes) > and lessens the filter load on routers. We are not using FS today for > attacks happening inside our AS, i came up with the idea what if we start > using it. > > > > I found a use case for BGP FS, might be useful for other SAFIs as well as > Robert wrote. But yes it is also possible having such a functionality wit= h > local enhancement (hopefully on major router vendors). > > > > Regards > > Er=C3=A7in TORUN > > *From:* Christoph Loibl > *Sent:* Friday, May 10, 2019 1:58 AM > *To:* ERCIN TORUN > *Cc:* Jakob Heitz (jheitz) ; Robert Raszuk < > robert@raszuk.net>; idr@ietf.org > *Subject:* Re: [Idr] update proposal to draft-ietf-idr-rfc5575bis-14 > > > > Hi Er=C3=A7in, Robert, Jakob, > > > > From Er=C3=A7in=E2=80=99s mail I understand that he wants his routers to = accept FS > routes only if the receiving router_id is encoded in the RT (MPLS is > mentioned in the mail but I think what Er=C3=A7in suggests has nothing to= do > with MPLS VPN). Er=C3=A7in also points out that the same functionality ca= n > already be achieved by tagging the FS-prefix with a specific community (o= r > whatever available) and have the router's bgp policy-framework > select/filter the (non-)appropriate FS filters (or even have the > route-reflectors do the filtering. btw. when it comes to RRs the suggeste= d > solution also seems a litte more tricky). > > > > The suggested solution eases the configuration in your specific use-case > since you do not need to manually (I doubt that you are doing that manual= ly > anyway - given the scale of the deployment that you describe) those > policies anymore. > > > > However, I agree with what Robert wrote in his last mail: > > > > This is *not* a problem to solve specifically for FS. For example you may > want to have a router import an IP unicast route only in case the router_= id > matches some extended community - why does it need to go into FS? It coul= d > be useful for other SAFIs as well! It may need additional considerations > because of BGP route propagation and scaling (route reflection, but also > propagation over multiple routing domains). On the other hand, since it c= an > be achieved with configuration already: Does this really need to go into > BGP? > > > > Cheers Christoph > > > > -- > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > > > > > > > On 09.05.2019, at 21:10, Robert Raszuk wrote: > > > > Hey Jakob, > > > > I am assuming he is using MPLS fabric for a reason ... One most likely > reason could be L3VPN :) Otherwise what would be the point to use MPLS to > start with ? Basic hierarchical routing ? And even for L3VPN MPLS in > transport layer. It is also not needed for isolating underlay from overla= y > tenants routes. > > > > Regardless as you know RTs do apply for any SAFI not just 128. > > > > The only point is sort of automation to router_id filtering ... I guess a= n > implementation can support it for any SAFI as well with an extra knob. Th= at > would not be specific to flow-spec by just a vendor's local enhancement. > > > > As you know FlowSpec's main role was to prevent DDoS. With that you never > know on which ASBR your distributed attacks arrive so pushing filters to > only subset of them is a questionable. If you have 10s or 100s of ASBRs y= ou > would need now to apply long list of matching RTs. > > > > The solution is not backwards compatible as current routers unless > upgraded with new knob would accept all filters anyway. I hope no one wan= ts > this to be active by default as it would kill RFC5575 and turn FlowSpec t= o > NetConf. > > > > If you want to limit the filters only to ASBRs maybe some more generic RT > needs to be defined - say "apply only on EBGP speakers" ? > > > > Overall abuse of FlowSpec seems to continue. P2MP distributed nature of > BGP propagation keeps being used as P2P config push protocol. I am just n= ot > sure when such use cases will stop popping up left and right. > > > > Best, > > R. > > > > > > On Thu, May 9, 2019 at 10:52 PM Jakob Heitz (jheitz) > wrote: > > Robert, > > > > Section 8 applies to VPNv4 flow spec. > > > > I see two differences in Ercin's proposal. > > First, it is for IP Flow Spec, rather than for VPN > > Second, the IPv4 address in the RT matches with the router-id. > > This avoids the requirement to allocate and manage another identifier to > match the RT. > > that is an operational advantage. > > > > I support Ercin's proposal. > > > > Regards, > > Jakob. > > > > *From:* Idr *On Behalf Of *Robert Raszuk > *Sent:* Thursday, May 9, 2019 9:38 AM > *To:* ERCIN TORUN > *Cc:* idr@ietf.org > *Subject:* Re: [Idr] update proposal to draft-ietf-idr-rfc5575bis-14 > > > > Hi Ercin, > > > > What you are asking/proposing has been standardized in the original > RFC5575 already many years ago. > > > > Please see section 8 specifically this paragraph: > > > > Propagation of this NLRI is controlled by matching Route Target > > extended communities associated with the BGP path advertisement with > > the VRF import policy, using the same mechanism as described in "BGP/ > > MPLS IP VPNs" [RFC4364 ] .. > > > > Thx, > Robert. > > > > > > On Thu, May 9, 2019 at 2:04 PM ERCIN TORUN > wrote: > > Hello All, > > > > My name is Ercin TORUN and I=E2= =80=99m > working in Turkcell Turkey (35M-mobile/2M-fixed customer, +digital > services) as an IP/MPLS Network Planning Engineer. I would like to propo= se > an update to draft-ietf-idr-rfc5575bis-14 > . > > > > By default all flowspec entries (filters..) are applied to all routers, > and unnecessary application of many filters can easily owerwhelm the > capacity of routers resources (e.g. TCAM). We are pushing layer3 to the > edges with solutions like seamless-mpls or leaf-spine next-generation DC > topologies which widens the layer3 domain easily over thousands of device= s. > It is best to filter =E2=80=9Cdirty=E2=80=9D traffic where it first enter= s a network. There > are ways to accept BGP announcements only on the targeted router, like > defining a community for each router and configuring policies, but an > automated way would be much more easier and less error-prone. Our idea is > using a route-taget to match with BGP Identifier so that only the targete= d > router might accept the announcement. > > > > All in all, I propose to add below text to draft-ietf-idr-rfc5575bis-14 > > > > > =E2=80=9C In a common use case, it is necessary to apply a filter to on= e or a > few > > routers and to apply many different filters to many different routers. > > By default, all filters are applied to all routers. In this use case, > > the unnecessary application of the many filters can easily overwhelm > > the capacity of the routers. To simplify this use case, > > route-targets may be used to apply the filters to only the needed > routers: > > > > If one or more IPv4-Address-Specific route-targets are present, then > > the IPv4 address of at least one route- > > target MUST match one of the BGP Identifiers of the receiver in order > > for the update to be accepted. > > =E2=80=9C > > > > Regards > > Er=C3=A7in TORUN > > > > [image: http://www.turkcell.com.tr/downloads/bireysel/img/Tcelldis.gif] > > > Bu elektronik posta ve onunla iletilen butun dosyalar sadece gondericisi > tarafindan almasi amaclanan yetkili gercek ya da tuzel kisinin kullanimi > icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin > icerigini aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz > kesinlikle yasaktir ve bu elektronik postayi derhal silmeniz gerekmektedi= r. > > TURKCELL bu mesajin icerdigi bilgilerin do=C4=9Frulu=C4=9Fu veya eksiksiz= oldugu > konusunda herhangi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne > sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve > saklanmasindan sorumlu degildir. Bu mesajdaki gorusler yalnizca gonderen > kisiye aittir ve TURKCELLin goruslerini yansitmayabilir > > Bu e-posta bilinen butun bilgisayar viruslerine karsi taranmistir. > ------------------------------ > > This e-mail and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you are not the intended recipient you are hereby notified > that any dissemination, forwarding, copying or use of any of the > information is strictly prohibited, and the e-mail should immediately be > deleted. > > TURKCELL makes no warranty as to the accuracy or completeness of any > information contained in this message and hereby excludes any liability o= f > any kind for the information contained therein or for the information > transmission, reception, storage or use of such in any way whatsoever. Th= e > opinions expressed in this message belong to sender alone and may not > necessarily reflect the opinions of TURKCELL.. > > This e-mail has been scanned for all known computer viruses. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > --0000000000005fb67f058884866e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thx for clarification.=C2=A0

=
So your use case is to use BGP as targeted config push. You seems not = worried that 600+ routers and RRs will get FS updates only for 599+ to drop= them.=C2=A0

I do think that BGP should *not* be u= sed for config push regardless if this is ACLs or SIDs or XYZ.=C2=A0
<= div>
The idea of original 5575 leverages BGP for real p2mp fi= lter push and that along with unicast validation are the only two reasons w= hy we used BGP for it to start with. In your use case neither of those two = reasons apply

Cheers,
R.

<= /div>


On Fri, May 10, 2019 at 9:22 AM ERCIN TORUN <ercin.torun@turkcell.com.tr>= wrote:

Hello Christoph, Jakob, Robert,

=C2=A0

We wanted to filter DDOS attacks happening i= nside our AS , attacks from customers to customers, so my idea is not relat= ed to MPLS VPN or filtering a DDOS attack coming from a transit provider. Customers layer= 3 connections are terminated on around 600 routers today, which will increa= se when we push down layer3 terminations further into the edge.

=C2=A0

As Christoph mentioned solution eases the co= nfiguration by taking out manual configuration (assuming a DDOS analyzer co= uld analyze the origin interface/router of the attack=C2=A0 and insert BGP router id i= nto FS routes) and lessens the filter load on routers. We are not using FS = today for attacks happening inside our AS, i came up with the idea what if = we start using it.

=C2=A0

I found a use case for BGP FS, might be usef= ul for other SAFIs as well as Robert wrote. But yes it is also possible hav= ing such a functionality with local enhancement (hopefully on major router vendors). =

=C2=A0

Regards

Er=C3=A7in TORUN

From: Christoph Loibl <c@tix.at>
Sent: Friday, May 10, 2019 1:58 AM
To: ERCIN TORUN <ercin.torun@turkcell.com.tr>
Cc: Jakob Heitz (jheitz) <jheitz@cisco.com>; Robert Raszuk <robert@raszuk.net>; idr@ietf.org
Subject: Re: [Idr] update proposal to draft-ietf-idr-rfc5575bis-14

=C2=A0

Hi=C2=A0Er=C3=A7in, Robert, Jakob,

=C2=A0

From=C2=A0Er=C3=A7in=E2=80=99s mail I understand tha= t he wants his routers to accept FS routes only if the receiving router_id = is encoded in the RT (MPLS is mentioned in the mail but I think what Er=C3= =A7in suggests has nothing to do with MPLS VPN). Er=C3=A7in also points out that the same functionality can already be achieved by tagging = the FS-prefix with a specific community (or whatever available) and have th= e router's bgp policy-framework select/filter the (non-)appropriate FS = filters (or even have the route-reflectors do the filtering. btw. when it comes to RRs the suggested solution also se= ems a litte more tricky).=C2=A0

=C2=A0

The suggested solution eases the configuration in yo= ur specific use-case since you do not need to manually (I doubt that you ar= e doing that manually anyway - given the scale of the deployment that you d= escribe) those policies anymore.=C2=A0

=C2=A0

However, I agree with what Robert wrote in his last = mail:=C2=A0

=C2=A0

This is *not* a problem to solve specifically for FS= . For example you may want to have a router import an IP unicast route only= in case the router_id matches some extended community - why does it need t= o go into FS? It could be useful for other SAFIs as well! It may need additional considerations because of BGP = route propagation and scaling (route reflection, but also propagation over = multiple routing domains). On the other hand, since it can be achieved with= configuration already: Does this really need to go into BGP?

=C2=A0

Cheers Christoph

=C2=A0

--=C2=A0
Christoph Loibl
c@tix.at=C2=A0| CL8-RIPE = | PGP-Key-ID:=C2=A00x4B2C0055 |=C2=A0http://www.nextlayer.at

=C2=A0

=C2=A0

=C2=A0

On 09.05.2019, at 21:10, Robert Raszuk <robert@raszuk.net> w= rote:

=C2=A0

Hey Jakob,

=C2=A0

I am assuming he is using MPLS fabric for a reason .= .. One most likely reason could be L3VPN :) Otherwise what would be the poi= nt to use MPLS to start with ? Basic hierarchical routing ? And even for L3= VPN MPLS in transport layer. It is also not needed for isolating underlay from overlay tenants routes.=C2=A0<= u>

=C2=A0

Regardless as you know RTs do apply for any SAFI not= just 128.=C2=A0

=C2=A0

The only point is sort of automation to router_id fi= ltering ... I guess an implementation can support it for any SAFI as well w= ith an extra knob. That would not be specific to flow-spec by just a vendor= 's local enhancement.=C2=A0

=C2=A0

As you know FlowSpec's main role was to prevent = DDoS. With that you never know on which ASBR your distributed attacks arriv= e so pushing filters to only subset of them is a questionable. If you have = 10s or 100s of ASBRs you would need now to apply long list of matching RTs.=C2=A0

=C2=A0

The solution is not backwards compatible as current = routers unless upgraded with new knob would accept all filters anyway. I ho= pe no one wants this to be active by default as it would kill RFC5575 and t= urn FlowSpec to NetConf.=C2=A0

=C2=A0

If you want to limit the filters only to ASBRs maybe= some more generic RT needs to be defined - say "apply only on EBGP sp= eakers" ?=C2=A0

=C2=A0

Overall abuse of FlowSpec seems to continue. P2MP di= stributed nature of BGP propagation keeps being used as P2P config push pro= tocol. I am just not sure when such use cases will stop popping up left and= right.=C2=A0

=C2=A0

Best,

R.

=C2=A0

=C2=A0

On Thu, May 9, 2019 at 10:52 PM Jakob Heitz (jheitz)= <jheitz@cisco.com= > wrote:

Robert,

=C2=A0

Section 8 applies to VP= Nv4 flow spec.

=C2=A0

I see two differences i= n Ercin's proposal.

First, it is for IP Flo= w Spec, rather than for VPN

Second, the IPv4 addres= s in the RT matches with the router-id.<= u>

This avoids the require= ment to allocate and manage another identifier to match the RT.

that is an operational = advantage.

=C2=A0

I support Ercin's p= roposal.

=C2=A0

Regards,

Jakob.

=C2=A0

From: Idr <idr-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Thursday, May 9, 2019 9:38 AM
To: ERCIN TORUN <ercin.torun@turkcell.com.tr>
Cc: idr@ietf.org
Subject: Re: [Idr] update proposal to draft-ietf-idr-rfc5575bis-14

=C2=A0

=C2=A0

On Thu, May 9, 2019 at 2:04 PM = ERCIN TORUN <ercin.torun@turkcell.com.tr> wrote:

Hello All,

=C2=A0

My name is Ercin T= ORUN and I=E2=80=99m working in Turkcell Turkey (35M-mobile/2M-fixed cu= stomer, +digital services) as an IP/MPLS Network Planning Engineer.=C2=A0 I= would like to propose an update to draft-ietf-idr-rfc5575bis-14.

=C2=A0

By default all flowspec entries (filters..) are appl= ied to all routers, and unnecessary application of many filters can easily = owerwhelm the capacity of routers resources (e.g. TCAM). We are pushing layer3 to the edges with solutions like seamless-mpl= s or leaf-spine next-generation DC topologies which widens the layer3 domai= n easily over thousands of devices. It is best to filter =E2=80=9Cdirty=E2= =80=9D traffic where it first enters a network. There are ways to accept BGP announcements only on the targeted router, like def= ining a community for each router and configuring policies, but an automate= d way would be much more easier and less error-prone. Our idea is using a r= oute-taget to match with BGP Identifier so that only the targeted router might accept the announcement.

=C2=A0

All in all, I propose to add below text to draft-ietf-idr-rfc5575bis-14

=C2=A0

=E2=80=9C=C2=A0=C2=A0 In a common use case, i= t is necessary to apply a filter to one or a few

=C2=A0=C2=A0 routers and to apply many differ= ent filters to many different routers.

=C2=A0=C2=A0 By default, all filters are appl= ied to all routers. In this use case,=

=C2=A0=C2=A0 the unnecessary application of t= he many filters can easily overwhelm<= /u>

=C2=A0=C2=A0 the capacity of the routers. To = simplify this use case,

=C2=A0 =C2=A0route-targets may be used to app= ly the filters to only the needed routers:

=C2=A0<= /u>

=C2=A0=C2=A0 If one or more IPv4-Address-Spec= ific route-targets are present, then<= /u>

=C2=A0=C2=A0 the IPv4 address of at least one= route-

=C2=A0=C2=A0 target MUST match one of the BGP= Identifiers of the receiver in order=

=C2=A0=C2=A0 for the update to be accepted.

=E2=80=9C<= /p>

=C2=A0

Regards

Er=C3=A7in TORUN



3D"http://www.turkcell.com.tr/downloads/bireysel/img/Tcelldis=

Bu elektronik posta ve= onunla iletilen butun dosyalar sadece gondericisi tarafindan almasi amacla= nan yetkili gercek ya da tuzel kisinin kullanimi icindir. Eger soz konusu yetkili alici degilseniz bu elektronik postanin icerigini = aciklamaniz, kopyalamaniz, yonlendirmeniz ve kullanmaniz kesinlikle yasakti= r ve bu elektronik postayi derhal silmeniz gerekmektedir.

TURKCELL bu mesajin ic= erdigi bilgilerin do=C4=9Frulu=C4=9Fu veya eksiksiz oldugu konusunda herhan= gi bir garanti vermemektedir. Bu nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden, alinmasindan ve saklanmasindan s= orumlu degildir. Bu mesajdaki gorusler yalnizca gonderen kisiye aittir ve T= URKCELLin goruslerini yansitmayabilir=

Bu e-posta bilinen but= un bilgisayar viruslerine karsi taranmistir.=

This e-mail and any fi= les transmitted with it are confidential and intended solely for the use of= the individual or entity to whom they are addressed. If you are not the intended recipient you are hereby notified that any dis= semination, forwarding, copying or use of any of the information is strictl= y prohibited, and the e-mail should immediately be deleted.

TURKCELL makes no warr= anty as to the accuracy or completeness of any information contained in thi= s message and hereby excludes any liability of any kind for the information contained therein or for the information transmis= sion, reception, storage or use of such in any way whatsoever. The opinions= expressed in this message belong to sender alone and may not necessarily r= eflect the opinions of TURKCELL..=

This e-mail has been s= canned for all known computer viruses.

_______________________________= ________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

=C2=A0

--0000000000005fb67f058884866e--