From nobody Mon Aug 1 01:54:06 2016 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 2EA5F12D563 for ; Mon, 1 Aug 2016 01:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HWLm5D-JrPSW for ; Mon, 1 Aug 2016 01:54:02 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 D827112D580 for ; Mon, 1 Aug 2016 01:53:57 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id g62so110536891lfe.3 for ; Mon, 01 Aug 2016 01:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=D60msAFe5kaLLcWwVnaQBcTFPaNhcm+lYOd3TXEYimU=; b=eT/D4iUIv9D9VZn8XWmDv/VK8NDoM2jDoKcePxetSHW7HIp5EJxTSJKjc+aoYwN4Mj DIgmH9CXOUre4tBZHm59LcqTAFI+KBk2jyPPzo5JyN7ZpjuUgKKoLErl2+MjocpEZFXB yhBG4QS6fUbSPpmpjUpF3YXa89l/0iHvdZFoGXiIHFeXJ2Sw8rhT/G8/R3fp66ILm1i3 yqxT4JPCWcGaqQu+xv4b8lRopYPokCyAFRtf8ljEF6Ptcm1BT3q9+NheDiuro10Ew/R+ akicu/aV5M058zKxYaoA9ObHBAJDl5ho5EZGsqplhFHC7RZ1BiHCsEq1bj+2kIWpKHKS qRmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=D60msAFe5kaLLcWwVnaQBcTFPaNhcm+lYOd3TXEYimU=; b=OH5Yo5i9MTogJaewzDQZZovK3rYqgBmiZq+i33Kn/06/YBQrPdqIPf2lP8qDgJJkYO CAtHJHZBEosb5bqIKCHMzSa5/H2FliBMILUtTf0porchdq9i06JG6ZnxyVX74WZL7DgD LLsmTp7+dDJdeJWifBDSr74y15MujWTft0hfiklkkIZXGwG9TpyM4UrWp5AEIHmjO2Ih x4tlJ6/xeEuuuweQMaD8uunnYSdXd22f2WieFuzt9GIv+qNHx+UuimInL224XW3kVK38 Eeh1I64SoJEf/V2MLvN/2Ynv0kvGhprFgvwV+AIri9hP2P/QqCazmZvv2uo16eXCP4GW wqGg== X-Gm-Message-State: AEkoouskKzSyc/pVWk1YL4SRpCP3lx4XJuVpvYelsLEnX/g5KpeCdZKCLlwoW9Gt9N/NRDl9+lPDOZyoL5wLpg== X-Received: by 10.25.214.40 with SMTP id n40mr18824916lfg.105.1470041635913; Mon, 01 Aug 2016 01:53:55 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.10.131 with HTTP; Mon, 1 Aug 2016 01:53:53 -0700 (PDT) In-Reply-To: <2138159007.9153002.1470032396712.JavaMail.yahoo@mail.yahoo.com> References: <76CD132C3ADEF848BD84D028D243C92774EEF7CF@NKGEML515-MBX.china.huawei.com> <5506bd9120c44493acb735085ead333a@XCH-ALN-014.cisco.com> <2138159007.9153002.1470032396712.JavaMail.yahoo@mail.yahoo.com> From: Robert Raszuk Date: Mon, 1 Aug 2016 10:53:53 +0200 X-Google-Sender-Auth: BmkZShyNt9h2mf0q73JQyQtmEPM Message-ID: To: Niloofar Fazlollahi Content-Type: multipart/alternative; boundary=001a114117068388cf0538febd85 Archived-At: Cc: "Keyur Patel \(keyupate\)" , idr wg Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 08:54:05 -0000 --001a114117068388cf0538febd85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Niloofar, Requesting just the prefix which previously got dropped due to inbound policy (no ORF no RTC) is very elegant. However let's observe few points here: * How often do you apply prefix lists on a full eBGP feeds ? The most prefix lists dropping prefixes inbound are either to your customers (and this is mainly permits not denys) and customers do not give you full routes but just a tiny subset. Full refresh there for a given SAFI is not an issue. * If you are doing eBGP prefix drops as DDoS mitigation you are helping the attacker as effectively you are cutting reachability to your customer's destinations. Use of more granular policy is recommended to hold specific attack at the data plane (rfc5575). * Last let's notice that during discussions on introducing Enhanced Route Refresh 3 years back your colleagues strongly highlighted that getting periodic full table from a peer is a real necessity in BGP due to possibly random state inconsistencies. Now it is interesting that the very same folks no longer remember it :) Ref: https://goo.gl/I6m3OS Cheers, Robert. On Mon, Aug 1, 2016 at 8:19 AM, Niloofar Fazlollahi < niloofar_fazlollahi@yahoo.com> wrote: > Hi Robert, > In response to your comment: > "If you pushed your prefix list with ORF then removing it will get you > the delta. > > If you filtered based on import RT then advertising RT in ORF or RTC will > get you the delta. > > So in what exact protocol cases you envision use case for this scoped one > time refresh ? And what exactly in your opinion should be the list of > parameters used to perform a query ? " > > There is also the case that policy is enforced locally, nor ORF and > neither RTC, e.g., route-map in with deny prefix-list. > Once the policy is removed, with cap 74, speaker can request refresh of > only the previously denied prefixes. > How to implement this optimization with ORF? > > Based on your previous email: > "For Match =3D PERMIT REMOVE action should result in *only* the delta > between whole table and remaining ORF entries. " > > If we send a PERMIT ADD for those prefixes and then PERMIT REMOVE, we wil= l > be refreshed with the whole AFI/SAFI assuming no other ORF is added > previously. > > Regards, > Niloofar > > > > On Friday, July 29, 2016 4:30 AM, Robert Raszuk wrote= : > > > Jakob, > > I did not make any judgement who is right and who is wrong. You did so le= t > me explain where you are missing it. > > #1 - As someone wisely said at the last IETF MAY =3D MAY NOT hence if spe= c > contains MAY it equally well could be interpreted in the opposite way. > Enough to say this is not a base to make any right or wrong judgement. > > #2 - This entire thread as well as this draft in question is all about > optimization. I must repeat that there is no problem in the first place s= o > receiving all routes in a given SAFI modulo ORF or RTC filter is just fin= e. > During policy change you issue Enhanced Route Refresh. > > However If this is not fine then I recommend to fix those inefficient > implementations which are generating excess of messages in the BGP UPDATE > rather then putting another layer of questionable band-aid on top of it. > > Thx, > R. > > On Fri, Jul 29, 2016 at 12:12 PM, Jakob Heitz (jheitz) > wrote: > > Wrong. RFC 5291 says: > > The speaker MUST re-advertise all the routes that have been > affected by the ORF entries carried in the message, but MAY also re- > advertise the routes that have not been affected by the ORF entries > carried in the message. > > > Thanks, > Jakob. > > > On Jul 29, 2016, at 12:45 AM, Robert Raszuk wrote: > > Hi Jakob, > > See inline ... > > On Fri, Jul 29, 2016 at 4:18 AM, Jakob Heitz (jheitz) > wrote: > > Just reading some of this. > A limited refresh is NOT the same thing as "Apply the ORF then remove it"= . > Suppose you want to refresh a subset of the routes. > You send an ORF to permit only the subset. > You receive the subset. > Now you remove the ORF. > You receive the whole table. > NOT what you wanted. > > > > =E2=80=8BIf this is what your implementation does then I recommend you fi= x it > first. > > For Match =3D DENY =E2=80=8BREMOVE action should result in *only* adverti= sement of > previously filtered entries. > > For Match =3D PERMIT REMOVE action should result in *only* the delta betw= een > whole table and remaining ORF entries. > > =E2=80=8BIn no case you get the whole table (other then removal of last O= RF PERMIT > entry). =E2=80=8B > > > > > Also, the use case is good. > The receiver dropped some routes due to policy. > The receiver changed the policy. > Now it wants a repeat of the previously dropped routes. > This is not a use case for ORF or RTC. > The thing is that ORF or RTC were already passing those routes, so > changing them is nonsense. > > > > =E2=80=8BFor this case you use Enhanced Route Refresh. As result you get = those > NLRIs which pass ORF or RTC the filters on a per AFI/SAFI basis. > > You have to be able to handle it anyway as when you boot you will get. > > If you pushed your prefix list with ORF then removing it will get you the > delta. > > If you filtered based on import RT then advertising RT in ORF or RTC will > get you the delta. > > So in what exact protocol cases you envision use case for this scoped one > time refresh ? And what exactly in your opinion should be the list of > parameters used to perform a query ? > > > Best, > R. > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > --001a114117068388cf0538febd85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Niloofar,

Requesting just the prefix which previously g= ot dropped due to inbound policy (no ORF no RTC) is very elegant.=C2=A0

However let's observe= few points here:

* Ho= w often do you apply prefix lists on a full eBGP feeds ? The most prefix li= sts dropping prefixes inbound are either to your customers (and this is mai= nly permits not denys) and customers do not give you full routes but just a= tiny subset. Full refresh there for a given SAFI is not an issue.=C2=A0

* If you are doing eBGP = prefix drops as DDoS mitigation you are helping the attacker as effectively= you are cutting reachability to your customer's destinations. Use of m= ore granular policy is recommended to hold specific attack at the data plan= e (rfc5575).

* Last le= t's notice that during discussions on introducing Enhanced Route Refres= h 3 years back your colleagues strongly highlighted that getting periodic f= ull table from a peer is a real necessity in BGP due to possibly random sta= te inconsistencies. Now it is interesting that the very same folks no longe= r remember it :)=C2=A0

Ref: https://goo.gl/I6m3OS

Cheers,
Robert.


On Mon, Aug 1, 2016 at 8:19 AM, Niloofar Fa= zlollahi <niloofar_fazlollahi@yahoo.com> wrote:<= br>
Hi Robert,
In response to your comment:
&q= uot;If you pushed your prefix list with ORF then removing it will get yo= u the delta.=C2=A0

If you filtered b= ased on import RT then advertising RT in ORF or RTC will get you the delta.= =C2=A0

So in what exact protocol cases you env= ision use case for this scoped one time refresh ? And what exactly in your = opinion should be the list of parameters used to perform a query ? "

There is also the case that policy is enforced locally, n= or ORF and neither RTC, e.g., route-map in with deny prefix-list.
Onc= e the policy is removed, with cap 74, speaker can request refresh of only t= he previously denied prefixes.
How to implement this optimization with OR= F?=C2=A0

Based on your previous email:
"For Match =3D PERMIT REMOVE action should result in *only* the delta b= etween whole table and remaining ORF entries. "

If we send a PERMIT ADD for those prefixes and then PERMIT REMOVE, we will= be refreshed with the whole AFI/SAFI assuming no other ORF is added previo= usly.

Regards,
Niloofar



<= font size=3D"2" face=3D"Arial"> On Friday, July 29, 2016 4:30 AM, Robert Ra= szuk <robert@rasz= uk.net> wrote:


Jakob,

I did not make any judgement who= is right and who is wrong. You did so let me explain where you are missing= it.=C2=A0

#1 - As someone wisely said at the last IETF MAY =3D MAY NO= T hence if spec contains MAY it equally well could be interpreted in the op= posite way. Enough to say this is not a base to make any right or wrong jud= gement.=C2=A0

#2 - This entire thread as well as this draft in questio= n is all about optimization. I must repeat that there is no problem in the = first place so receiving all routes in a given SAFI modulo ORF or RTC filte= r is just fine. During policy change you issue Enhanced Route Refresh.

=
However If this is not fine then I recommend to fix those inefficient impl= ementations which are generating excess of messages in the BGP UPDATE rathe= r then putting another layer of questionable band-aid on top of it.=C2=A0
<= br>
Thx,
R.

On Fri, Jul 29, 2016 at 12:12 PM, Jako= b Heitz (jheitz) <jheitz@cisco.com> wrote:
Wrong. RFC 5291 says:
The speaker MUST re-advert=
ise all the routes that have been
   affected by the ORF entries carried in the message, but MAY also re-
   advertise the routes that have not been affected by the ORF entries
   carried in the message.

 Thanks,
Jakob.


On Jul 29, 2016, at 12:45 AM, Robert Raszuk <robert@raszuk.net> wrot= e:

Hi Jakob,

See inline ...=C2=A0

On Fri, Jul 29, 2016 at 4:18 AM, Jakob Heitz (jheitz) <= jheitz@cisco.com> wrote:
Just reading some of thi= s.
A limited refresh is NOT= the same thing as "Apply the ORF then remove it".<= /span>
Suppose you want to refr= esh a subset of the routes.
You send an ORF to permi= t only the subset.
You receive the subset.<= u>
Now you remove the ORF.<= u>
You receive the whole ta= ble.
NOT what you wanted.


=E2=80=8BIf this is what your implementation does then I recommend you fix = it first.=C2=A0

For Match =3D DENY =E2=80=8BREMOVE action should result in *only* advertise= ment of previously filtered entries.=C2=A0

For Match =3D PERMIT REMOVE action should result in *only* the delta betwee= n whole table and remaining ORF entries.=C2=A0

=E2=80=8BIn no case you get the whole table (other then removal of last ORF= PERMIT entry). =E2=80=8B


=C2=A0
Also, the use case= is good.
The receiver dropped som= e routes due to policy.
The receiver changed the= policy.
Now it wants a repeat of= the previously dropped routes.
This is not a use case f= or ORF or RTC.
The thing is that ORF or= RTC were already passing those routes, so changing them is nonsense.


=E2=80=8BFor this case you use Enhanced Route Refresh. As result you get th= ose NLRIs which pass ORF or RTC the filters on a per AFI/SAFI basis.=C2=A0<= /div>

You have to be able to handle it anyway as when you boot you will get.

If you pushed your prefix list with ORF then removing it will get you the d= elta.=C2=A0

If you filtered based on import RT then advertising RT in ORF or RTC will g= et you the delta.=C2=A0

So in what exact protocol cases you envision use case for this scoped one t= ime refresh ? And what exactly in your opinion should be the list of parame= ters used to perform a query ?=C2=A0


Best,
R.







_______= ________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.or= g/mailman/listinfo/idr


<= /div>

--001a114117068388cf0538febd85-- From nobody Mon Aug 1 04:37:37 2016 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 B7EB112D771 for ; Mon, 1 Aug 2016 04:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 zg0jW4mRo5va for ; Mon, 1 Aug 2016 04:37:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE5D12D772 for ; Mon, 1 Aug 2016 04:37:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bUBXJ-0002NN-47; Mon, 01 Aug 2016 11:37:33 +0000 Date: Mon, 01 Aug 2016 20:37:30 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <76CD132C3ADEF848BD84D028D243C92774EEF7CF@NKGEML515-MBX.china.huawei.com> <5506bd9120c44493acb735085ead333a@XCH-ALN-014.cisco.com> <2138159007.9153002.1470032396712.JavaMail.yahoo@mail.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 11:37:36 -0000 > * How often do you apply prefix lists on a full eBGP feeds ? every single one, every time. bogons, default, longer than /24, a t1 in the as path when the receiver is a t1 (ok, that's not a full feed), ... welcome to routing in the real ugly world. randy From nobody Mon Aug 1 04:43:01 2016 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 4E23312D780 for ; Mon, 1 Aug 2016 04:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IOJwfYmr7Jv9 for ; Mon, 1 Aug 2016 04:42:59 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 B432912D77D for ; Mon, 1 Aug 2016 04:42:58 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b199so113578669lfe.0 for ; Mon, 01 Aug 2016 04:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=f5RmR/xc9pXcDMXeA0iAJZRy0YZFkOzoyZ9zHr0peSU=; b=0F/KQFnuiVvPDCKVh/iZJlr6/dXJIHVm1Z+htLCjKonOIrvIV7WnLoESDva/3wDaHm IFBD6nMKX2dJAxIrKm3NfTAE+RjgK8WBRHvhfiK3CACBYMYlCRN+5qW9a8EZ/F4al6hy xYVHZnMZns5bhulgSp0EJ1WuSaogGGhoRb/eoIvLoG4e7Ci4eYZ8gbe+sX+4LDXGEOAV 7NvlnSt1MfweTxFM6TRBsZdATq/bhVMvfcYnvlqs6BY7Nftw2+itA1BOx3R4rGOQ3AfK t6JcNTzQ2+gFPk3DkISJfHzq6hfS3VvkM4rbd3OlXmaVmS8/xBRj605mB1AkI73PzFDm g8uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=f5RmR/xc9pXcDMXeA0iAJZRy0YZFkOzoyZ9zHr0peSU=; b=XHvraNPf20dSzDlaUbf0znDp8wfPB5dEkfZTSpSZktIwYQF5nKztQCBPpQncPHMmFz H6C4D52PTZCOatCf6FsQXyMlUEkZmJchOc5r2NA57xS4MfIo0j3/MylhDf3sb+vOe7fD przyZLgKK6Bgz4ubsNRiE5OdhUGqrsDUxzfrkFxW18lFhIiR4XrBurin8M5aHM1XSa/D DljaB+Q5ysSK3d1SWkNJxc8GRHHLEv4kpYXcUWeFb+ZoElQQAGP3X7MnS54nzrxhf9vI YMGLHTTg7mwuM2QTO7SPNEdURGX7FYYWEHJMaXoFoQzMff2m9PXt6jP0K1y+v2WNf1kD lOxA== X-Gm-Message-State: AEkooutUElY3SjmNlrdFtLYzz+P46A324Kob/ccDjMYQ3nThUzVU1Txr7jvfLvxMxcyL523F1HSlg3h531cxSA== X-Received: by 10.25.37.18 with SMTP id l18mr19527455lfl.88.1470051776803; Mon, 01 Aug 2016 04:42:56 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.10.131 with HTTP; Mon, 1 Aug 2016 04:42:55 -0700 (PDT) Received: by 10.25.10.131 with HTTP; Mon, 1 Aug 2016 04:42:55 -0700 (PDT) In-Reply-To: References: <76CD132C3ADEF848BD84D028D243C92774EEF7CF@NKGEML515-MBX.china.huawei.com> <5506bd9120c44493acb735085ead333a@XCH-ALN-014.cisco.com> <2138159007.9153002.1470032396712.JavaMail.yahoo@mail.yahoo.com> From: Robert Raszuk Date: Mon, 1 Aug 2016 13:42:55 +0200 X-Google-Sender-Auth: gPkDHCvgQE07myVWiHixAxzZ1WU Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a114117e2f53dea0539011982 Archived-At: Cc: idr wg Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 11:43:00 -0000 --001a114117e2f53dea0539011982 Content-Type: text/plain; charset=UTF-8 Randy, Of course you have bogons, policies with AS_PATH .. tons of regex etc ... but: #1 you do not usually remove them #2 if you modify them you just can't ask you peer for specific prefix and assume your BGP got synced up correctly. That's the bigger picture here. Cheers R. On Aug 1, 2016 1:37 PM, "Randy Bush" wrote: > > * How often do you apply prefix lists on a full eBGP feeds ? > > every single one, every time. bogons, default, longer than /24, a t1 in > the as path when the receiver is a t1 (ok, that's not a full feed), ... > welcome to routing in the real ugly world. > > randy > --001a114117e2f53dea0539011982 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Randy,

Of course you have bogons, policies with AS_PATH .. tons of = regex etc ... but:

#1 you do not usually remove them

#2 if you modify them you just can't ask you peer for sp= ecific prefix and assume your BGP got synced up correctly.

That's the bigger picture here.

Cheers
R.


On Aug 1, 2016 1:= 37 PM, "Randy Bush" <randy@ps= g.com> wrote:
> * How often do you apply prefix lists on a full eBGP feeds ?

every single one, every time.=C2=A0 bogons, default, longer than /24, a t1 = in
the as path when the receiver is a t1 (ok, that's not a full feed), ...=
welcome to routing in the real ugly world.

randy
--001a114117e2f53dea0539011982-- From nobody Mon Aug 1 04:48:39 2016 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 8C68912D5C3 for ; Mon, 1 Aug 2016 04:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 EIeIXKtech1r for ; Mon, 1 Aug 2016 04:48:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E8A12D7AB for ; Mon, 1 Aug 2016 04:48:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bUBi0-0002PV-Gb; Mon, 01 Aug 2016 11:48:36 +0000 Date: Mon, 01 Aug 2016 20:48:34 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <76CD132C3ADEF848BD84D028D243C92774EEF7CF@NKGEML515-MBX.china.huawei.com> <5506bd9120c44493acb735085ead333a@XCH-ALN-014.cisco.com> <2138159007.9153002.1470032396712.JavaMail.yahoo@mail.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 11:48:38 -0000 > Of course you have bogons, policies with AS_PATH .. tons of regex etc > ... but: your question was absolute. i answered. > #1 you do not usually remove them bogon lists shrink as address space is allocated. yes, v4 not so much these days, but v6 yes. > #2 if you modify them you just can't ask you peer for specific prefix > and assume your BGP got synced up correctly. we were not discussing 93 other possible mechanisms. you asked a question; i answered. the goal was not to see how much you could wiggle, despite it being election season. randy From nobody Mon Aug 1 04:56:15 2016 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 1C44012D7D7; Mon, 1 Aug 2016 04:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 vh6Q1kuHleZY; Mon, 1 Aug 2016 04:56:13 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C5412D7C5; Mon, 1 Aug 2016 04:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2829; q=dns/txt; s=iport; t=1470052572; x=1471262172; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OwIFTv3MwMCr7Pk+HWZEusj5nt52W9VmYjEBNyVu+uo=; b=XEhngHfgfXirUrqaLIj2XSulTsRblZa+sMrKn5ZbskZiP3OMDdJQPhiT cwWAz6X5ufQ9v1E+76RcfhrUlrrddlSYXc8QJOo6P8tGxFNjEDHu6m9n6 oY4fWgM51ka7YO5O4JYBAc6lrDiBICkQxD/TyXU2/M+XiQTT4hsIs2ACI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAwBoOJ9X/5FdJa1dgndOgVIGtAWFB?= =?us-ascii?q?oF9hh0CgSw4FAEBAQEBAQFdJ4RfAQV5EAIBCAQ7BzIUEQIEAQ0FiDHAYgEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARyGKoRNihsFjk+FIYVDAY5+gWuEWoh6kCYBHjaDe?= =?us-ascii?q?m6HUn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,454,1464652800"; d="scan'208,217";a="130484744" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 11:56:12 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u71BuB27023722 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Aug 2016 11:56:12 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 1 Aug 2016 06:56:11 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Mon, 1 Aug 2016 06:56:11 -0500 From: "Alvaro Retana (aretana)" To: "Shitanshu Shah (svshah)" , "draft-ietf-idr-sla-exchange@ietf.org" Thread-Topic: AD Review of draft-ietf-idr-sla-exchange-08 Thread-Index: AQHRzyvlvU+08NLC/kOdoAF0zVY3yqA0ScSA Date: Mon, 1 Aug 2016 11:56:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.6] Content-Type: multipart/alternative; boundary="_000_D3C4AFE31377B9aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-sla-exchange-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 11:56:14 -0000 --_000_D3C4AFE31377B9aretanaciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 6/25/16, 5:52 PM, "Shitanshu Shah (svshah)" > wrote: Hi! Just to close the loop on this as I see the draft is about to expire... Thank you for your review and detailed review comments.. Shitanshu and I had a brief conversation in Berlin. As mentioned in my rev= iew, and beyond general clarity and consistency, the main items I want the = WG to address are: (1) the SLA definition: please have tsvwg or the Transpo= rt Directorate review the document (not just look for conflicts of work), a= nd (2) a clear indication of what functionality belongs in BGP (and which p= arts don't). Thanks! Alvaro. --_000_D3C4AFE31377B9aretanaciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On 6/25/16, 5:52 PM, "Shitanshu Shah (svshah)" <svshah@cisco.com> wrote:

Hi!

Just to close the loop on this as I see the draft is about to expire&#= 8230;

Thank you for your review and detailed review comments..

Shitanshu and I had a brief conversation in Berlin.  As mentioned= in my review, and beyond general clarity and consistency, the main items I= want the WG to address are: (1) the SLA definition: please have tsvwg or t= he Transport Directorate review the document (not just look for conflicts of work), and (2) a clear indication of what = functionality belongs in BGP (and which parts don't).

Thanks!

Alvaro.
--_000_D3C4AFE31377B9aretanaciscocom_-- From nobody Mon Aug 1 09:25:21 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7820712D0A6; Mon, 1 Aug 2016 09:25:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160801162520.32663.39596.idtracker@ietfa.amsl.com> Date: Mon, 01 Aug 2016 09:25:20 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 16:25:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Inter-domain SLA Exchange Attribute Authors : Shitanshu Shah Keyur Patel Sandeep Bajaj Luis Tomotaki Mohamed Boucadair Filename : draft-ietf-idr-sla-exchange-09.txt Pages : 31 Date : 2016-08-01 Abstract: Network administrators typically enforce Quality of Service (QoS) policies according to Service Level Agreement (SLA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, often manual, process and prone to errors. This document specifies an optional transitive attribute to signal SLA parameters in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplifying and facilitating some of the complex provisioning tasks in situations where BGP is available as a routing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-sla-exchange-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-sla-exchange-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 1 09:29:39 2016 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 9163112D0F8; Mon, 1 Aug 2016 09:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ZAAH4qRuYoYT; Mon, 1 Aug 2016 09:29:35 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D116E12B05B; Mon, 1 Aug 2016 09:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5627; q=dns/txt; s=iport; t=1470068974; x=1471278574; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GjCQYFmUsArHZQckNJ0KfRxI5FYZybDw5mJmtfhxYUg=; b=gPhISgR3BrW72oOYePzVmvFUS0kDEddK7s9xZlGIqA52FY3Y66SGEAmh PuIRekTjXuzI0XIHo9PInR9AhTcKxcYUVyhhRhVLlp3khIZrSQq8QeAXf EtpHo4yhRl/wTNXcxns61tVrVZuw1OiPdIDZ3w6oGMKJwhrLeLpxMu4Kp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAgDpd59X/4YNJK1dgndOgVIGtAeFB?= =?us-ascii?q?oF9hh0CgS44FAEBAQEBAQFdJ4ReAQEFeRACAQgRAwECKAcyFAkIAgQBDQWIMcB?= =?us-ascii?q?1AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIp3hGCFOwWOT4UhhUMBjn6Ba4RaiHqMM?= =?us-ascii?q?IN2AR42g3puhxZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,456,1464652800"; d="scan'208,217";a="303479007" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2016 16:29:34 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u71GTXEk025037 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Aug 2016 16:29:33 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 1 Aug 2016 11:29:33 -0500 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1210.000; Mon, 1 Aug 2016 11:29:33 -0500 From: "Shitanshu Shah (svshah)" To: "Alvaro Retana (aretana)" , "draft-ietf-idr-sla-exchange@ietf.org" Thread-Topic: AD Review of draft-ietf-idr-sla-exchange-08 Thread-Index: AQHRzyvlvU+08NLC/kOdoAF0zVY3yqA0ScSAgAAaHYA= Date: Mon, 1 Aug 2016 16:29:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.38.91] Content-Type: multipart/alternative; boundary="_000_D3C4C6121E757svshahciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , Susan Hares , "idr@ietf.org" Subject: Re: [Idr] AD Review of draft-ietf-idr-sla-exchange-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 16:29:36 -0000 --_000_D3C4C6121E757svshahciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just submitted a revision of the draft that incorporates review comments in= cluding clear indication of what functionality belongs in BGP and what does= not. Regards, Shitanshu From: "Alvaro Retana (aretana)" > Date: Monday, August 1, 2016 at 4:56 AM To: Shitanshu Shah >, "draft-ietf= -idr-sla-exchange@ietf.org" > Cc: "idr-chairs@ietf.org" >, Susan Hares >, "idr@ietf.org" > Subject: Re: AD Review of draft-ietf-idr-sla-exchange-08 On 6/25/16, 5:52 PM, "Shitanshu Shah (svshah)" > wrote: Hi! Just to close the loop on this as I see the draft is about to expire... Thank you for your review and detailed review comments.. Shitanshu and I had a brief conversation in Berlin. As mentioned in my rev= iew, and beyond general clarity and consistency, the main items I want the = WG to address are: (1) the SLA definition: please have tsvwg or the Transpo= rt Directorate review the document (not just look for conflicts of work), a= nd (2) a clear indication of what functionality belongs in BGP (and which p= arts don't). Thanks! Alvaro. --_000_D3C4C6121E757svshahciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Just submitted a revision of the draft that incorporates review commen= ts including clear indication of what functionality belongs in BGP and what= does not.

Regards,
Shitanshu

From: "Alvaro Retana (aretana)= " <aretana@cisco.com> Date: Monday, August 1, 2016 at 4:5= 6 AM
To: Shitanshu Shah <svshah@cisco.com>, "draft-ietf-idr-sla-exchange@ietf.org" <draft-= ietf-idr-sla-exchange@ietf.org>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: AD Review of draft-iet= f-idr-sla-exchange-08

On 6/25/16, 5:52 PM, "Shitanshu Shah (svshah)" <svshah@cisco.com> wrote:

Hi!

Just to close the loop on this as I see the draft is about to expire&#= 8230;

Thank you for your review and detailed review comments..

Shitanshu and I had a brief conversation in Berlin.  As mentioned= in my review, and beyond general clarity and consistency, the main items I= want the WG to address are: (1) the SLA definition: please have tsvwg or t= he Transport Directorate review the document (not just look for conflicts of work), and (2) a clear indication of what = functionality belongs in BGP (and which parts don't).

Thanks!

Alvaro.
 --_000_D3C4C6121E757svshahciscocom_-- From nobody Mon Aug 1 15:56:07 2016 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 28B2C12D65E for ; Mon, 1 Aug 2016 15:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 aQBW-AtQSgAj for ; Mon, 1 Aug 2016 15:56:04 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFAB12D1B3 for ; Mon, 1 Aug 2016 15:56:04 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id B83536A488; Mon, 1 Aug 2016 22:56:03 +0000 (UTC) Date: Mon, 1 Aug 2016 22:56:03 +0000 From: heasley To: Randy Bush Message-ID: <20160801225603.GA60542@shrubbery.net> References: <5506bd9120c44493acb735085ead333a@XCH-ALN-014.cisco.com> <2138159007.9153002.1470032396712.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 22:56:05 -0000 Mon, Aug 01, 2016 at 08:48:34PM +0900, Randy Bush: > > #1 you do not usually remove them > > bogon lists shrink as address space is allocated. yes, v4 not so much > these days, but v6 yes. ACLs, at various points in our network, change daily. From nobody Mon Aug 1 16:05:49 2016 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 E6CDF12D5D2 for ; Mon, 1 Aug 2016 16:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QMKLl9fh9v7w for ; Mon, 1 Aug 2016 16:05:46 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 42FBE12D112 for ; Mon, 1 Aug 2016 16:05:46 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id l69so125923594lfg.1 for ; Mon, 01 Aug 2016 16:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5rQHHx10FPO1Ad2jVb8W/oYcj061e+4t8ondGkY72H8=; b=FdaHaHy/tfA2ToxfE0oPgLsjQ+EyIZ3CIXVoQbqCrF/nPL4S7CNvVnjF+130rRzyWx 1p9WbER/h3jJjDBUJxOK4OdSsWa8qT1e1hk61sUB8vG+NmGvQmHWXPgknrbb3f4JYmiH UO8okVXojUKy4p74DQJNjH1jkj0NlDGr9L8pUcBh4zqLO6C5yqGbxnxQ7nmXHI6/XWgk Zem+nf2LXnBeOzjKKlD3JEZy+RKrI7693uLs6uPyGxHyawsZ5Yyw/M3txZupUB8x1Q/j EN0kVPhfodZFxSIPtx1tZIv97JFiLrBo3MhP1u2QodYp5CRsVPV4LFOtBDMVtOtaKbaq ksmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5rQHHx10FPO1Ad2jVb8W/oYcj061e+4t8ondGkY72H8=; b=RbHxVL+guaRv/HjKLfh7aYpfMInorlUmlYiAzj9xtOyH1kLt/HtL/w+vZNx1NsostM CR4opQ3OqvEFxocSscXWgfdobXw0h4fqAYvTlx9151rGRmJOkK+XnZQaidX8B1eVAld1 BPmX5StN+OO66WaCBNZEg4nPb7XE8VIvpMeHhKaR/49vCSG9G/ub2cAkBQ4mcQ+S1Dac t4/3LIbk6mcCPM6LR6/xd4rG+MLVUhuvpJP3tlUfyLYp1Rr2/GCr1O95dXpLJHLkTQlp l2hSSZtHKqnpups/8rEN+yPKbfPazbl0ihXDx4vQd7JiAMX/wfhOksCz0t7PvGEhzSLU 34HQ== X-Gm-Message-State: AEkooustSvAIY662/MsWrTx38PGdSyCPoYvYMBRkWRBoMisOb/86NUaBMFp4Lh7VdDI/Qd+cqCkNRyasqTRUmw== X-Received: by 10.25.37.18 with SMTP id l18mr20490247lfl.88.1470092744356; Mon, 01 Aug 2016 16:05:44 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.10.131 with HTTP; Mon, 1 Aug 2016 16:05:42 -0700 (PDT) In-Reply-To: <20160801225603.GA60542@shrubbery.net> References: <5506bd9120c44493acb735085ead333a@XCH-ALN-014.cisco.com> <2138159007.9153002.1470032396712.JavaMail.yahoo@mail.yahoo.com> <20160801225603.GA60542@shrubbery.net> From: Robert Raszuk Date: Tue, 2 Aug 2016 01:05:42 +0200 X-Google-Sender-Auth: Ojn9oiwdvbSSe2sqLWe9glnBcxI Message-ID: To: heasley Content-Type: multipart/alternative; boundary=001a114117e2d07b8c05390aa3a4 Archived-At: Cc: idr wg Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 23:05:48 -0000 --001a114117e2d07b8c05390aa3a4 Content-Type: text/plain; charset=UTF-8 To make this time my question much more precise ... It is very obvious that inbound eBGP policy changes very often for 94 reasons. However the real point is how many of those policy changes can be mapped to newly proposed scoped refresh vs just addressed with per SAFI enhanced full route refresh. If NOC folks will prove that upon policy adjustment automated query to peers prefix by prefix is useful the only outstanding question will remain how to deal with BGP inconsistencies as pointed out earlier in this thread. Thx, R. On Tue, Aug 2, 2016 at 12:56 AM, heasley wrote: > Mon, Aug 01, 2016 at 08:48:34PM +0900, Randy Bush: > > > #1 you do not usually remove them > > > > bogon lists shrink as address space is allocated. yes, v4 not so much > > these days, but v6 yes. > > ACLs, at various points in our network, change daily. > --001a114117e2d07b8c05390aa3a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

To make th= is time my question much more precise ...

It is very obvious that inbound eBGP policy changes ver= y often for 94 reasons.=C2=A0

However the real point is how many of those policy changes can be = mapped to newly proposed scoped refresh vs just addressed with per SAFI enh= anced full route refresh. =C2=A0

If NOC folks will prove that upon policy adjustment automated qu= ery to peers prefix by prefix is useful the only outstanding question will = remain how to deal with BGP inconsistencies as pointed out earlier in this = thread.

Thx,
R.


=

On Tue, Aug= 2, 2016 at 12:56 AM, heasley <heas@shrubbery.net> wrote:
Mon, Aug 01, 2016 at 08:48:34PM +0900, Ran= dy Bush:
> > #1 you do not usually remove them
>
> bogon lists shrink as address space is allocated.=C2=A0 yes, v4 not so= much
> these days, but v6 yes.

ACLs, at various points in our network, change daily.

--001a114117e2d07b8c05390aa3a4-- From nobody Mon Aug 1 17:08:57 2016 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 8ECA412D0A3 for ; Mon, 1 Aug 2016 17:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 QtUCTDSzCS9y for ; Mon, 1 Aug 2016 17:08:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDA812B05D for ; Mon, 1 Aug 2016 17:08:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bUNGC-0005Ng-TB; Tue, 02 Aug 2016 00:08:41 +0000 Date: Tue, 02 Aug 2016 09:08:38 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <5506bd9120c44493acb735085ead333a@XCH-ALN-014.cisco.com> <2138159007.9153002.1470032396712.JavaMail.yahoo@mail.yahoo.com> <20160801225603.GA60542@shrubbery.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: John Heasly , idr wg Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 00:08:56 -0000 > To make this time my question much more precise ... you asked if we changed filters on full feeds. the answer is yes. > It is very obvious that inbound eBGP policy changes very often for 94 > reasons. then why did you ask? > However the real point is how many of those policy changes can be > mapped to newly proposed scoped refresh vs just addressed with per > SAFI enhanced full route refresh. focusing on the full feeds about which you asked, what happens when i update to accept prefixes from a new v6 /12 allocated by the iana? do i really need the load of a full refresh of the v6 table? is it polite to my upstreams? will it be if v6 is actually widely deployed? from my pov, route refresh is not a small hammer. the trade-off is the complexity, and concomitant bugs, of scoped refresh vs more bgp bouncy bouncy. i bow to heas's wisdom. randy From nobody Mon Aug 1 19:58:07 2016 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 6F6F312D777 for ; Mon, 1 Aug 2016 19:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LuxjyqafqB_D for ; Mon, 1 Aug 2016 19:58:05 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 9D8BB12D751 for ; Mon, 1 Aug 2016 19:58:04 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id g62so128310307lfe.3 for ; Mon, 01 Aug 2016 19:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=s6ZP8LXxXbbBxGkerWVO1lunfgJycSpVQ4gq0QnFDAI=; b=piRKXiDuI3byTYXv3+HqwACBxaZxLOdDhh7aGJZVSnd1O9+Y/aRY5N74Qhgt9YBwpf bP1OjBPvJUjWepZlDLR6zqboGOVEajMHPDac4ZI3PIXJl78ZyVwiOFj1UMl5DEMZ5tOQ Hy9Woz+xMCa6waNtLTJYkPI/erf+3HZC2InknwV/MnzfqocFXn6eCffDKjJD25VivtMJ YY6k+K00/misyIub1S2IGvbUJG/C99UbD5lKFTbe3IMC9cW8G0QkDfjq1M2pQG2tJaqn Sg2j+RLxPK9eCrV+px8fKDK8X/FUT2XlB52sbNKmI6DWuomTb51Gq7VqBrEFD3lyPGjB OumQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=s6ZP8LXxXbbBxGkerWVO1lunfgJycSpVQ4gq0QnFDAI=; b=mqAVvN9NDK+xF3PonISGd6AZNq8da7Fou8kYlCcf70J2ADIjruGG/ZNcQGjdyFMhX9 KMFdn+BMiThxxwhlBd1RCKkwz4O//L+935UPBgLlL0ld/Iz/6XhLhGZn667+vpguEKRT qQdXDc9BxJt3dcgYRyaFMP7SJ6iKWJmlh7HvDZzRhgMhc6lbR6ZeK/t2AqFHwDLpKrtJ WnC/8wmMRNiac9X6O8tDbqYV1cwkkDLDRwgw3b/8y+OIeAHGc6pPxvvdhTnxa/Khvpbs 9NauTGk/AanaoaCY+nERalHtGIilJuHG1mU+FsInIJwHAu+tldHlTjP776ldBfKl66UH FgSw== X-Gm-Message-State: AEkoousUMHOjqdEg7YDrAltwWMhcOEwYWhTqMoX5IUuFG+nr7e1ZU7gmRNnjl6i40tc7kpzFcYZQQ2US3xKw6g== X-Received: by 10.25.32.136 with SMTP id g130mr21366955lfg.184.1470106682575; Mon, 01 Aug 2016 19:58:02 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.10.131 with HTTP; Mon, 1 Aug 2016 19:58:00 -0700 (PDT) Received: by 10.25.10.131 with HTTP; Mon, 1 Aug 2016 19:58:00 -0700 (PDT) In-Reply-To: References: <5506bd9120c44493acb735085ead333a@XCH-ALN-014.cisco.com> <2138159007.9153002.1470032396712.JavaMail.yahoo@mail.yahoo.com> <20160801225603.GA60542@shrubbery.net> From: Robert Raszuk Date: Tue, 2 Aug 2016 04:58:00 +0200 X-Google-Sender-Auth: ujHntjtgz-y2BLcmO3OcL9EaVsI Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a1140244a98d03c05390de2ab Archived-At: Cc: heasley , idr wg Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 02:58:06 -0000 --001a1140244a98d03c05390de2ab Content-Type: text/plain; charset=UTF-8 > you asked if we changed filters on full feeds. the answer is yes. What I really asked with context of this thread was if changes which are being applied in inbound policy on full feeds can be represented by parameters which are proposed to be used as query. You answered yes for full v6 table of today's 30k routes some changes can be mapped to a prefix. Cool. > > It is very obvious that inbound eBGP policy changes very often for 94 > > reasons. > > then why did you ask? As this is not policy change. This duscussion is about policy changes which can be mapped to scoped refresh. > focusing on the full feeds about which you asked, what happens when i > update to accept prefixes from a new v6 /12 allocated by the iana? do > i really need the load of a full refresh of the v6 table? is it polite > to my upstreams? will it be if v6 is actually widely deployed? Please observe that with one time scoped refresh you still need to be able to handle the full feed (ex. booting time). Let's also notice that since we are now talking about being polite nothing (other then your local configuration) forces you to drop everything which you do not need. You are welcome to keep everything you receive in Adj_Rib_In and modify your policy 100 times a day with zero impact to your peers. Kind regards, Robert. --001a1140244a98d03c05390de2ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


> you asked if we changed filters on full feeds.=C2=A0 the answer is yes= .

What I really asked with context of this thread was if chang= es which are being applied in inbound policy on full feeds can be represent= ed by parameters which are proposed to be used as query.

You answered yes for full v6 table of today's 30k routes= some changes can be mapped to a prefix. Cool.

> > It is very obvious that inbound eBGP policy change= s very often for 94
> > reasons.
>
> then why did you ask?

As this is not policy change. This duscussion is about polic= y changes which can be mapped to scoped refresh.

> focusing on the full feeds about which you asked, what = happens when i
> update to accept prefixes from a new v6 /12 allocated by the iana?=C2= =A0 do
> i really need the load of a full refresh of the v6 table?=C2=A0 is it = polite
> to my upstreams?=C2=A0 will it be if v6 is actually widely deployed?

Please observe that with one time scoped refresh you still n= eed to be able to handle the full feed (ex. booting time). Let's also n= otice that since we are now talking about being polite nothing (other then = your local configuration) forces you to drop everything which you do not ne= ed. You are welcome to keep everything you receive in Adj_Rib_In and modify= your policy 100 times a day with zero impact to your peers.

Kind regards,
Robert.

--001a1140244a98d03c05390de2ab-- From nobody Wed Aug 3 02:24:59 2016 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 AEE0112D0CA; Wed, 3 Aug 2016 02:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.905 X-Spam-Level: X-Spam-Status: No, score=-3.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 FV2vXw05nlth; Wed, 3 Aug 2016 02:24:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9222412D0A9; Wed, 3 Aug 2016 02:24:54 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 21130A03C0; Wed, 3 Aug 2016 11:24:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id E5DB61A0083; Wed, 3 Aug 2016 11:24:52 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0301.000; Wed, 3 Aug 2016 11:24:52 +0200 From: To: "mpls@ietf.org" , "idr@ietf.org" Thread-Topic: draft-rosen-mpls-rfc3107bis-01 Thread-Index: AdHtXhKcw/8U4DNRSc6RiIGfzLyKjA== Date: Wed, 3 Aug 2016 09:24:51 +0000 Message-ID: <5633_1470216293_57A1B865_5633_2905_1_53C29892C857584299CBF5D05346208A0F973F79@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F973F79OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [Idr] draft-rosen-mpls-rfc3107bis-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 09:24:58 -0000 --_000_53C29892C857584299CBF5D05346208A0F973F79OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, Thanks for the draft. I may have 2 comments. 1) Interaction with BGP Graceful Restart " [RFC4724] ("Graceful Restart Mechanism for BGP") describes a procedure that allows routes learned over a given BGP session to be maintained when the session fails and then restarts. This procedure requires the entire RIB to be transmitted when the session restarts. If the Multiple Labels Capability for a given AFI/SAFI had been exchanged on the failed session, but is not exchanged on the restarted session, then any prefixes advertised in that AFI/SAFI with multiple labels MUST be explicitly withdrawn. Similarly, if the maximum label count, specified in the Capability for a given AFI/SAFI is reduced, an prefixes advertised with more labels than are valid for the current session MUST be explicitly withdrawn." I don't think that the prefix "MUST be explicitly withdrawn." I'd rather sa= y that the prefix "MUST not be re-advertised" (...with a number of labels e= xceeding the capability of the receiver). IOW, the new BGP session simply = needs to comply with the spec, nothing new. But I'd agree that to be on the= safe side, explicitly spelling out this case may be appropriate. But we co= uld also note that rfc6793 (AS 4-octet) has a related problem and does not = talk about it. Under the control of the IDR WG that is in copy. BTW, IMHO this document looks heavier on the BGP side than on the MPLS side= , especially with the new additions in -01 e.g. interaction with GR, Enhanc= ed-GR which are not trivial, even for the IDR WG. Especially since 3107bis = mostly fixes BGP related points (e.g. capability, different BGP encoding de= pending on the capability) 2) Interop with RFC 3107 < If a BGP implementation, not conformant with the current document, encodes multiple labels in the NLRI but has not sent and received the "Multiple Labels" Capability, a BGP implementation that does conform with the current document will likely reset the BGP session." I agree, but it's rather usual that a non-conformant implementation creates= issues. In this case, I think that it would be fair to highlight that an implementa= tion compliant with RFC 3107 and supporting the advertisement of multiple l= abels, is _not_ compliant with rfc3107bis, hence not interoperable, hence w= ill likely reset the BGP session. I think it would be useful to have a section talking about the interoperabi= lity between RFC3107 and rfc3107bis, in particular for network operator to = read and be able to perform the appropriate checks before deployments. Thanks, Regards, --Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_53C29892C857584299CBF5D05346208A0F973F79OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

Thanks for the draft.

I may have 2 comments.

 

 

1) &nbs= p;    Interaction with BGP Gr= aceful Restart

 

“   [RFC4724] ("Graceful Restart Mechanism for BGP&quo=
t;) describes a
   procedure that allows routes learned=
 over a given BGP session to be
   maintained when the session fails an=
d then restarts.  This procedure
   requires the entire RIB to be transm=
itted when the session restarts.
 
   If the Multiple Labels Capability fo=
r a given AFI/SAFI had been
   exchanged on the failed session, but=
 is not exchanged on the
   restarted session, then any prefixes=
 advertised in that AFI/SAFI with
   multiple labels MUST be explicitly w=
ithdrawn.  Similarly, if the
   maximum label count, specified in th=
e Capability for a given AFI/SAFI
   is reduced, an prefixes advertised w=
ith more labels than are valid
   for the current session MUST be expl=
icitly withdrawn.”
 

I don’t think that the pr= efix “MUST be explicitly withdrawn.” I’d rather say that = the prefix “MUST not be re-advertised” (…with a number of= labels exceeding the capability of the receiver).  IOW, the new BGP s= ession simply needs to comply with the spec, nothing new. But I’d agree that to be= on the safe side, explicitly spelling out this case may be appropriate. Bu= t we could also note that rfc6793 (AS 4-octet) has a related problem and do= es not talk about it.

Under the control of the IDR WG= that is in copy.

BTW, IMHO this document looks h= eavier on the BGP side than on the MPLS side, especially with the new addit= ions in -01 e.g. interaction with GR, Enhanced-GR which are not trivial, ev= en for the IDR WG. Especially since 3107bis mostly fixes BGP related points (e.g. capability, different BGP en= coding depending on the capability)

 

 

2) &nbs= p;    Interop with RFC 3107

 

« 

   If a B= GP implementation, not conformant with the current document,

   encode= s multiple labels in the NLRI but has not sent and received the<= /span>

   "= Multiple Labels" Capability, a BGP implementation that does conform

   with t= he current document will likely reset the BGP session.”

 

I agree, but it’s rather = usual that a non-conformant implementation creates issues.

In this case, I think that it w= ould be fair to highlight that an implementation compliant with RFC 3107 an= d supporting the advertisement of multiple labels, is _not_ complian= t with rfc3107bis, hence not interoperable, hence will likely reset the BGP session.

I think it would be useful to h= ave a section talking about the interoperability between RFC3107 and rfc310= 7bis, in particular for network operator to read and be able to perform the= appropriate checks before deployments.

 

Thanks,

Regards,

--Bruno

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_53C29892C857584299CBF5D05346208A0F973F79OPEXCLILM21corp_-- From nobody Mon Aug 8 12:20:47 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA5512D501; Mon, 8 Aug 2016 12:20:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147068403330.32229.9560982511148394696.idtracker@ietfa.amsl.com> Date: Mon, 08 Aug 2016 12:20:33 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-route-oscillation-stop-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 19:20:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : BGP Persistent Route Oscillation Solutions Authors : Daniel Walton Alvaro Retana Enke Chen John Scudder Filename : draft-ietf-idr-route-oscillation-stop-04.txt Pages : 9 Date : 2016-08-08 Abstract: The routing information reduction by BGP Route Reflection or Confederation can result in persistent internal BGP route oscillations with certain routing setup and network topologies. This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillation-stop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-route-oscillation-stop-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-route-oscillation-stop-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 8 14:02:51 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B157D12B027; Mon, 8 Aug 2016 14:02:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147069017072.32217.14575891342897045264.idtracker@ietfa.amsl.com> Date: Mon, 08 Aug 2016 14:02:50 -0700 Archived-At: Cc: draft-ietf-idr-route-oscillation-stop@ietf.org, idr@ietf.org, idr-chairs@ietf.org, The IESG , shares@ndzh.com, rfc-editor@rfc-editor.org Subject: [Idr] Protocol Action: 'BGP Persistent Route Oscillation Solutions' to Proposed Standard (draft-ietf-idr-route-oscillation-stop-04.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 21:02:50 -0000 The IESG has approved the following document: - 'BGP Persistent Route Oscillation Solutions' (draft-ietf-idr-route-oscillation-stop-04.txt) as Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillation-stop/ Technical Summary This document presents two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED- induced route oscillations (subject to certain commonly adopted topological constrains). Working Group Summary Strong consensus. Good discussion on the list. https://www.ietf.org/mail-archive/web/idr/current/msg14201.html Document Quality Implemented in Juniper, Cisco RTG-DIR review: Tony Przygienda This was discussed for over 5 years, and deployed. We are just slow in getting it standardized. Personnel Document Shepherd: Susan Hares AD: Alia Atlas (Alvaro Retana is the author) From nobody Tue Aug 16 03:53:37 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D7612D5EB; Tue, 16 Aug 2016 03:53:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147134481228.22986.4375755969354564176.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 03:53:32 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-trill-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 10:53:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Distribution of TRILL Link-State using BGP Authors : Weiguo Hao Donald E. Eastlake Susan K. Hares Sujay Gupta Muhammad Durrani Yizhou Li Filename : draft-ietf-idr-ls-trill-02.txt Pages : 13 Date : 2016-08-16 Abstract: This draft describes a TRILL link state and MAC address reachability information distribution mechanism using a BGP LS extension. External components such as an SDN Controller can use the information for topology visibility, troubleshooting, network automation, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-trill/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-ls-trill-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-trill-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 16 07:03:29 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCFF12D82E; Tue, 16 Aug 2016 07:03:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147135620824.22928.6974407320806663250.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 07:03:28 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-impl-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 14:03:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Inter-domain SLA Exchange Implementation Report-02 Authors : Shitanshu Shah Keyur Patel Filename : draft-ietf-idr-sla-exchange-impl-02.txt Pages : 5 Date : 2016-08-16 Abstract: This document is a report of implementations based on [IDR-SLA]. [IDR-SLA] introduces a new BGP attribute to exchange QoS SLA parameters between BGP peers. Current status of the implementation report covers Cisco implementation on 2 different OS, ExaBGP implementation and inter-operability results between them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange-impl/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-sla-exchange-impl-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-sla-exchange-impl-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 16 15:08:27 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2934112D550; Tue, 16 Aug 2016 15:08:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147138530412.23010.6034622644370311175.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 15:08:24 -0700 Archived-At: Cc: idr-chairs@ietf.org, idr@ietf.org, jgs@bgp.nu Subject: [Idr] idr - New Meeting Session Request for IETF 97 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 22:08:24 -0000 A new meeting session request has just been submitted by John Scudder, a Chair of the idr working group. --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: John Scudder Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: First Priority: trill i2rs i2nsf netconf bess sidr netmod rtgwg Second Priority: sdnrg nfvrg teas Third Priority: dots rtgarea Special Requests: I believe our attendee count of 105 last meeting was an undercount -- the room was full to capacity (actually, past capacity) so some people who wanted to attend were turned away. --------------------------------------------------------- From nobody Wed Aug 17 10:36:55 2016 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 B35FB12DB07; Wed, 17 Aug 2016 10:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no 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 sVJkbIIaapnz; Wed, 17 Aug 2016 10:36:32 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C75C12DB86; Wed, 17 Aug 2016 10:36:32 -0700 (PDT) Received: from [192.168.0.103] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8A26818013E2; Wed, 17 Aug 2016 19:36:30 +0200 (CEST) To: Eric C Rosen , Mach Chen , "draft-rosen-mpls-rfc3107bis.all@ietf.org" , "mpls-chairs@ietf.org" References: <041801d1ecdb$317d1910$94774b30$@olddog.co.uk> <5d7fcd92-f663-50fc-4057-9827746886ca@juniper.net> From: Loa Andersson Message-ID: <6d39a0bf-df2d-8a33-3194-f693760683d8@pi.nu> Date: Wed, 17 Aug 2016 19:36:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5d7fcd92-f663-50fc-4057-9827746886ca@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" , idr@ietf.org, bess-chairs@ietf.org, BESS , idr-chairs@ietf.org Subject: [Idr] Question raised in the MPLS-RT review of draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 17:36:35 -0000 Eric, et.al., (copied also idr-chairs and idr-list + bess-chairs and bess-list) For those of you that are not subscribed to the mpls-list. - the mpls wg has started the initial steps for working group adoption, there are three steps -- mpls-rt review (what you see below is the follow-up discussion on that review) -- IPR poll, will be sent out soon -- working group adoption poll (wgap), that poll will be copied to the idr and bess. Hopefully we can that shortly. I'm sending this to mpls, idr and bess working group, since it has to do where things should be documented. On 2016-08-17 17:59, Eric C Rosen wrote: > Hi Mach, > > Thanks for your review. > > On 8/3/2016 4:51 AM, Mach Chen wrote: >> I have only one comment regarding to Section 5. IMHO, although it's >> informational, the description about the relationship between SAFI-1 >> and SAFI-4 routes should not belong to this document, it's a more >> common description that is not specific to this label binding process. >> I'd suggest to remove this section if there is no any other reasons. > > Differing interpretations about the relationship between SAFI-1 and > SAFI-4 are a very common source of interoperability problems among > implementations of different vendors. Thus I think it is very useful to > document this issue and to call attention to some of the differing > interpretations. I think this document is an appropriate place for this > information; even though this information is not about label binding, it > is about the semantics of SAFI-4. I agree that this needs to be documented! I can accept that it is done in draft-rosen-mpls-rfc3107bis, but I would like to have all three wg's agree to this. I see a few alternatives - we could document this is in draft-rosen-mpls-rfc3107bis; or - we could write a separate document - we could find another document where this has a better fit than in draft-rosen-mpls-rfc3107bis - any other suggestion Let us know if you have an opinion. Please send your responses to the mpls wg mailing list (mpls@ietf.org). /Loa mpls wg-co-chair > > Eric -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Aug 18 12:58:59 2016 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 19DB912B04F; Thu, 18 Aug 2016 12:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 y0fZ89CgI4DQ; Thu, 18 Aug 2016 12:49:05 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89F712B069; Thu, 18 Aug 2016 12:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4320; q=dns/txt; s=iport; t=1471549745; x=1472759345; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jAx/G4XUPSSrUl7CZxlGefsaSm5l+mqg6R2kZYGE6lA=; b=Iv5jdKRzUbykRgglyr41ccaVl0Lk86If/4JhmfacYW8SToaOvD4To1cv fiurMZr6D7KQUq4RLw0etOiOg6PJQaDxET2zmu/5YFKKhKq8LGtd7RDzK gDM35HiOusYC+QDpPS/1+BViEPKzV3Hug01GMXXxB1hAlCecbTPJCsfcg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAgDEELZX/4UNJK1dg0NWfAe3Y4F9J?= =?us-ascii?q?IV5AhyBVTgUAgEBAQEBAQFeJ4RfAQUBASERNwMEBw4CAgEIGAICJgICAhkMCxU?= =?us-ascii?q?QAgQBDQWIMQ6tI5AaAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwUFfIl2hBIRATOCa?= =?us-ascii?q?oJaBYYPkzUBjBeDBoFrhFyJAow7g3cBHjaDem6Fdzd/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,541,1464652800"; d="scan'208";a="311902897" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Aug 2016 19:49:03 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u7IJn37w017446 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Aug 2016 19:49:03 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 18 Aug 2016 15:49:02 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 18 Aug 2016 15:49:02 -0400 From: "Acee Lindem (acee)" To: Loa Andersson , Eric C Rosen , Mach Chen , "draft-rosen-mpls-rfc3107bis.all@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] Question raised in the MPLS-RT review of draft-rosen-mpls-rfc3107bis Thread-Index: AQHR+YmR0S/RSyfjp0yPMnkA4TqQ4Q== Date: Thu, 18 Aug 2016 19:49:02 +0000 Message-ID: References: <041801d1ecdb$317d1910$94774b30$@olddog.co.uk> <5d7fcd92-f663-50fc-4057-9827746886ca@juniper.net> <6d39a0bf-df2d-8a33-3194-f693760683d8@pi.nu> In-Reply-To: <6d39a0bf-df2d-8a33-3194-f693760683d8@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: text/plain; charset="utf-8" Content-ID: <89DD1181A6DA1A4289D0D4500128C2D7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 18 Aug 2016 12:58:57 -0700 Cc: "mpls@ietf.org" , "idr-chairs@ietf.org" , "bess-chairs@ietf.org" , BESS , "idr@ietf.org" Subject: Re: [Idr] [mpls] Question raised in the MPLS-RT review of draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 19:49:07 -0000 SGkgTG9hLCBldCBhbCwgDQoNClNpbmNlIEkgY29tbWVudGVkIG9uIHRoZSBNUExTLVJUIHJldmll dyB3aXRoIHJlc3BlY3QgdG8gdGhlIElEUi1zcGVjaWZpYw0KY29udGVudCwgdGhlcmUgbWF5IGJl IHNvbWUgY29uZnVzaW9uIGFzIHRvIHdoZXJlIEkgc3RhbmQgb24gdGhlIG93bmVyc2hpcA0Kb2Yg dGhpcyBkcmFmdC4gSeKAmXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kIGFncmVlIHdpdGgg dGhlIGFwcHJvYWNoDQpkZXNjcmliZWQgYmVsb3cuIEnigJltIGNvbnZpbmNlZCB3ZSB3aWxsIGdl dCB0aGUgcmlnaHQgbGV2ZWwgY3Jvc3MtV0cgcmV2aWV3DQphbG9uZyBhcyB3ZSByZWNvZ25pemUg dGhhdCBpdCBkb2VzIHNwYW4gbXVsdGlwbGUgV0dzLiBJIHdvdWxkIGV4cGVjdCB0aGF0DQp3ZeKA mWxsIGhhdmUgaW1wbGVtZW50YXRpb25zIGNvbmZvcm1pbmcgdG8gdGhlIGRyYWZ0IGluIHRoZSBu ZWFyIGZ1dHVyZS4NCg0KVGhhbmtzLA0KQWNlZQ0KDQpPbiA4LzE3LzE2LCAxOjM2IFBNLCAibXBs cyBvbiBiZWhhbGYgb2YgTG9hIEFuZGVyc3NvbiINCjxtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24g YmVoYWxmIG9mIGxvYUBwaS5udT4gd3JvdGU6DQoNCj5FcmljLCBldC5hbC4sIChjb3BpZWQgYWxz byBpZHItY2hhaXJzIGFuZCBpZHItbGlzdCArIGJlc3MtY2hhaXJzIGFuZA0KPmJlc3MtbGlzdCkN Cj4NCj5Gb3IgdGhvc2Ugb2YgeW91IHRoYXQgYXJlIG5vdCBzdWJzY3JpYmVkIHRvIHRoZSBtcGxz LWxpc3QuDQo+DQo+LSB0aGUgbXBscyB3ZyBoYXMgc3RhcnRlZCB0aGUgaW5pdGlhbCBzdGVwcyBm b3Igd29ya2luZyBncm91cCBhZG9wdGlvbiwNCj4gICB0aGVyZSBhcmUgdGhyZWUgc3RlcHMNCj4g ICAtLSBtcGxzLXJ0IHJldmlldyAod2hhdCB5b3Ugc2VlIGJlbG93IGlzIHRoZSBmb2xsb3ctdXAg ZGlzY3Vzc2lvbiBvbg0KPiAgICAgIHRoYXQgcmV2aWV3KQ0KPiAgIC0tIElQUiBwb2xsLCB3aWxs IGJlIHNlbnQgb3V0IHNvb24NCj4gICAtLSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwgKHdn YXApLCB0aGF0IHBvbGwgd2lsbCBiZSBjb3BpZWQgdG8NCj4gICAgICB0aGUgaWRyIGFuZCBiZXNz LiBIb3BlZnVsbHkgd2UgY2FuIHRoYXQgc2hvcnRseS4NCj4NCj5JJ20gc2VuZGluZyB0aGlzIHRv IG1wbHMsIGlkciBhbmQgYmVzcyB3b3JraW5nIGdyb3VwLCBzaW5jZSBpdCBoYXMNCj50byBkbyB3 aGVyZSB0aGluZ3Mgc2hvdWxkIGJlIGRvY3VtZW50ZWQuDQo+DQo+DQo+T24gMjAxNi0wOC0xNyAx Nzo1OSwgRXJpYyBDIFJvc2VuIHdyb3RlOg0KPj4gSGkgTWFjaCwNCj4+DQo+PiBUaGFua3MgZm9y IHlvdXIgcmV2aWV3Lg0KPj4NCj4+IE9uIDgvMy8yMDE2IDQ6NTEgQU0sIE1hY2ggQ2hlbiB3cm90 ZToNCj4+PiBJIGhhdmUgb25seSBvbmUgY29tbWVudCByZWdhcmRpbmcgdG8gU2VjdGlvbiA1LiBJ TUhPLCBhbHRob3VnaCBpdCdzDQo+Pj4gaW5mb3JtYXRpb25hbCwgdGhlIGRlc2NyaXB0aW9uIGFi b3V0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBTQUZJLTENCj4+PiBhbmQgU0FGSS00IHJvdXRl cyBzaG91bGQgbm90IGJlbG9uZyB0byB0aGlzIGRvY3VtZW50LCBpdCdzIGEgbW9yZQ0KPj4+IGNv bW1vbiBkZXNjcmlwdGlvbiB0aGF0IGlzIG5vdCBzcGVjaWZpYyB0byB0aGlzIGxhYmVsIGJpbmRp bmcgcHJvY2Vzcy4NCj4+PiBJJ2Qgc3VnZ2VzdCB0byByZW1vdmUgdGhpcyBzZWN0aW9uIGlmIHRo ZXJlIGlzIG5vIGFueSBvdGhlciByZWFzb25zLg0KPj4NCj4+IERpZmZlcmluZyBpbnRlcnByZXRh dGlvbnMgYWJvdXQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIFNBRkktMSBhbmQNCj4+IFNBRkkt NCBhcmUgYSB2ZXJ5IGNvbW1vbiBzb3VyY2Ugb2YgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyBh bW9uZw0KPj4gaW1wbGVtZW50YXRpb25zIG9mIGRpZmZlcmVudCB2ZW5kb3JzLiAgVGh1cyBJIHRo aW5rIGl0IGlzIHZlcnkgdXNlZnVsIHRvDQo+PiBkb2N1bWVudCB0aGlzIGlzc3VlIGFuZCB0byBj YWxsIGF0dGVudGlvbiB0byBzb21lIG9mIHRoZSBkaWZmZXJpbmcNCj4+IGludGVycHJldGF0aW9u cy4gIEkgdGhpbmsgdGhpcyBkb2N1bWVudCBpcyBhbiBhcHByb3ByaWF0ZSBwbGFjZSBmb3IgdGhp cw0KPj4gaW5mb3JtYXRpb247IGV2ZW4gdGhvdWdoIHRoaXMgaW5mb3JtYXRpb24gaXMgbm90IGFi b3V0IGxhYmVsIGJpbmRpbmcsIGl0DQo+PiBpcyBhYm91dCB0aGUgc2VtYW50aWNzIG9mIFNBRkkt NC4NCj4NCj5JIGFncmVlIHRoYXQgdGhpcyBuZWVkcyB0byBiZSBkb2N1bWVudGVkISBJIGNhbiBh Y2NlcHQgdGhhdCBpdCBpcyBkb25lDQo+aW4gZHJhZnQtcm9zZW4tbXBscy1yZmMzMTA3YmlzLCBi dXQgSSB3b3VsZCBsaWtlIHRvIGhhdmUgYWxsIHRocmVlIHdnJ3MNCj5hZ3JlZSB0byB0aGlzLiBJ IHNlZSBhIGZldyBhbHRlcm5hdGl2ZXMNCj4NCj4tIHdlIGNvdWxkIGRvY3VtZW50IHRoaXMgaXMg aW4gZHJhZnQtcm9zZW4tbXBscy1yZmMzMTA3YmlzOyBvcg0KPi0gd2UgY291bGQgd3JpdGUgYSBz ZXBhcmF0ZSBkb2N1bWVudA0KPi0gd2UgY291bGQgZmluZCBhbm90aGVyIGRvY3VtZW50IHdoZXJl IHRoaXMgaGFzIGEgYmV0dGVyIGZpdCB0aGFuIGluDQo+ICAgZHJhZnQtcm9zZW4tbXBscy1yZmMz MTA3YmlzDQo+LSBhbnkgb3RoZXIgc3VnZ2VzdGlvbg0KPg0KPkxldCB1cyBrbm93IGlmIHlvdSBo YXZlIGFuIG9waW5pb24uDQo+DQo+UGxlYXNlIHNlbmQgeW91ciByZXNwb25zZXMgdG8gdGhlIG1w bHMgd2cgbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnKS4NCj4NCj4vTG9hDQo+bXBscyB3Zy1j by1jaGFpcg0KPg0KPj4NCj4+IEVyaWMNCj4NCj4tLSANCj4NCj4NCj5Mb2EgQW5kZXJzc29uICAg ICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPlNlbmlv ciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+SHVhd2Vp IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5tcGxz IG1haWxpbmcgbGlzdA0KPm1wbHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCg0K From nobody Tue Aug 23 05:09:13 2016 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 87DF412D942 for ; Tue, 23 Aug 2016 05:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 gDcxdWGppFNF for ; Tue, 23 Aug 2016 05:09:10 -0700 (PDT) Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D66312D943 for ; Tue, 23 Aug 2016 05:09:10 -0700 (PDT) Received: from [92.60.6.198] (helo=[10.55.3.175]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1bcAOv-00081u-Sx for idr@ietf.org; Tue, 23 Aug 2016 14:01:57 +0200 From: Christoph Loibl X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_8E757A2E-7972-4D1D-9D58-12FB566BA78F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Tue, 23 Aug 2016 14:08:56 +0200 Message-Id: <65345B6C-D24F-4F32-BF3C-E9343A7C61E1@tix.at> To: idr@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 12:09:12 -0000 --Apple-Mail=_8E757A2E-7972-4D1D-9D58-12FB566BA78F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, We submitted a new draft and are happy to receive feedback: Since interoperability is key to an flowspec Internet deployment we = tried to clarify the ambiguous parts of the flowspec RFC 5575 in order = to allow a consistent implementation by equipment vendors. Title: draft-loibl-bacher-idr-flowspec-clarification = https://datatracker.ietf.org/doc/draft-loibl-bacher-idr-flowspec-clarifica= tion/ The reason for this draft submission is, that we recently performed a = rather large flowspec interop test (the main goal was to evaluate = possible inter-AS flowspec scenarios in a multi vendor environment) and = discovered many bugs and vendor interop problems that we want to solve. Unfortunately we currently cannot share all our findings in a test = report, because we hit some serious bugs that have (under circumstances) = potential to remotely melt down entire networks and are working with the = vendors to get bugs fixed. Christoph -- Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at --Apple-Mail=_8E757A2E-7972-4D1D-9D58-12FB566BA78F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAle8PN4ACgkQ0m2Mp0ssAFWKowCg67ScPWseNubd6kdXeKFgwFlP fxsAoL3GWbQnRQYWdnYvU7hrUGjzJCJt =QjVw -----END PGP SIGNATURE----- --Apple-Mail=_8E757A2E-7972-4D1D-9D58-12FB566BA78F-- From nobody Tue Aug 23 05:54:05 2016 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 EEC9A12D0C2 for ; Tue, 23 Aug 2016 05:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 C6TWz3eehh9u for ; Tue, 23 Aug 2016 05:54:02 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 9303612B065 for ; Tue, 23 Aug 2016 05:54:02 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id z190so105173515qkc.0 for ; Tue, 23 Aug 2016 05:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lJGoase+T/yMLyYU6CwBuTgcA5JNIJrzlY+/2UMigTk=; b=N/q+V0jmGQ9gqa7c7uAnfnhVJiXWBOZwvLNLXSgudJo2NdixptqeH6c4ndWgLz/eG+ YAvJtDz9C3ZB4crlkns7wrlZBulEgyfJHk7d0TaZWgY4NpaTqDXkmxaBsrNrzGq3t4+O SmfvpanQZyKB/MvRVcDkY9iM1dRYdff2a58nuAUczpZU7nx2CFgEuJHf6s68iuUT4xPY IJkYw0rLMOplOmpj7u5I0u0KGUQi1WlG/+AAanDXhapT0nsX1LRVaOh5RkvwOMAWNXwy oTiqega4zH1y+vzTSis/2VCR0CgZ33EmB5GTTCOMiaXmAfbpSLu7SR3Sus3tt6K3ck+Y EctQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lJGoase+T/yMLyYU6CwBuTgcA5JNIJrzlY+/2UMigTk=; b=dXCgkisNSGDOqR3XJZOjm8a5SQVa3I7dbjKXLoG8mP57/a/jhPG4n7yBM1GEY9v4ct YQr1Rr2Y8QnmW5bmCRTSCy09jG76ohzNI8itrNu/O5zHVvF1adTTVpUZ6RZs/7+2rwXB zBK3kGfth4S9DpBZ2kYrRGi6ZZe26MelUSZpcTSeT4/zXerxj/aJDzmsITxSOFleOqjX TFZOoFpljH7mqTV3JUgnlpG3UIlNjjyFoiEfgdKlMpC3aEjfvcE1l6ZBHZlSzH5kzQ3B Xvc0j5ZGUGgoqzx3IDZc2q7lT4wBjXGf21vJC3G/SNw8H9Se1d4T40UXhBn3XvTiYDkq 7h0A== X-Gm-Message-State: AE9vXwPlR+qYn8IKnYcxc5pX5Ql2sSDVxl33FtTHa1gB1BV1xBiFhGxeZZXiYx+OA6POJ8f/cPTwI7rLl3rRFQ== X-Received: by 10.55.140.135 with SMTP id o129mr7448489qkd.2.1471956841610; Tue, 23 Aug 2016 05:54:01 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.30.130 with HTTP; Tue, 23 Aug 2016 05:54:00 -0700 (PDT) In-Reply-To: <65345B6C-D24F-4F32-BF3C-E9343A7C61E1@tix.at> References: <65345B6C-D24F-4F32-BF3C-E9343A7C61E1@tix.at> From: Robert Raszuk Date: Tue, 23 Aug 2016 14:54:00 +0200 X-Google-Sender-Auth: V8m3cQgPRv1xauiMnPewlA-VTKU Message-ID: To: Christoph Loibl , martin.bacher@t-mobile.at Content-Type: multipart/alternative; boundary=001a114eafecab48e8053abca8e1 Archived-At: Cc: idr wg Subject: Re: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 12:54:05 -0000 --001a114eafecab48e8053abca8e1 Content-Type: text/plain; charset=UTF-8 Dear Christoph and Martin, Thank you very much for coming up with this document. Indeed it may help avoid some misinterpretation the intention of RFC5575 by implementors. I agree with all comments provided perhaps excluding those proposed in section 5. The overall intention of validation was to make sure that originator of given unicast prefix (and here it means at any point of time) is authorized to inject a filter for it. There are few cases of course to consider ... and really it also depends how strong an ISP implements say origin validation or other forms of BGP Sec. If I can trust that all paths for a given prefix are valid it should be sufficient to only validate flow spec NLRI against any path present in the BGP table for it matching say the left most value of AS_PATH attribute or originator are the same in unicast and flow spec routes. While I realize that 5575 says "best-match" while we are at clarifying it maybe we should discuss this more. Similarly many operators use flow-spec only within their own ASes and by default first thing they do is disable validation all together. If we want to promote use of flow spec inter-as maybe we should also account that local use case and by spec relax the validation all together for it. Another debate is if this should be enforced only at the EBGP boundary or also at IBGP ... Bottom line we want to prevent ACL churn on the router in the events of best path changes. To summarize if you ever will ask for WG acceptance I am in full support of this work. Cheers, Robert. On Tue, Aug 23, 2016 at 2:08 PM, Christoph Loibl wrote: > Hi, > > We submitted a new draft and are happy to receive feedback: > > Since interoperability is key to an flowspec Internet deployment we tried > to clarify the ambiguous parts of the flowspec RFC 5575 in order to allow a > consistent implementation by equipment vendors. > > Title: draft-loibl-bacher-idr-flowspec-clarification > > https://datatracker.ietf.org/doc/draft-loibl-bacher-idr- > flowspec-clarification/ > > The reason for this draft submission is, that we recently performed a > rather large flowspec interop test (the main goal was to evaluate possible > inter-AS flowspec scenarios in a multi vendor environment) and discovered > many bugs and vendor interop problems that we want to solve. > > Unfortunately we currently cannot share all our findings in a test report, > because we hit some serious bugs that have (under circumstances) potential > to remotely melt down entire networks and are working with the vendors to > get bugs fixed. > > Christoph > > -- > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a114eafecab48e8053abca8e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Christoph and Martin,

Thank you very much for coming up = with this document. Indeed it may help avoid some misinterpretation the int= ention of RFC5575 by implementors.=C2=A0

=
I agree with all comments provided perhaps excluding tho= se proposed in section 5.=C2=A0

The overall intention of validation was to make sure that origina= tor of given unicast prefix (and here it means at any point of time) is aut= horized to inject a filter for it.=C2=A0

=
There are few cases of course to consider ... and really= it also depends how strong an ISP implements say origin validation or othe= r forms of BGP Sec.=C2=A0

If I can trust that all paths for a given prefix are valid it should be= sufficient to only validate flow spec NLRI against any path present in the= BGP table for it matching say the left most value of AS_PATH attribute or = originator are the same in unicast and flow spec routes.=C2=A0

While I realize that 5575 says &qu= ot;best-match" while we are at clarifying it maybe we should discuss t= his more.=C2=A0

Simila= rly many operators use flow-spec only within their own ASes and by default = first thing they do is disable validation all together. If we want to promo= te use of flow spec inter-as maybe we should also account that local use ca= se and by spec relax the validation all together for it.=C2=A0

Another debate is if this should b= e enforced only at the EBGP boundary or also at IBGP ...=C2=A0

Bottom line we want to prevent ACL= churn on the router in the events of best path changes.=C2=A0

To summarize if you ever will ask = for WG acceptance I am in full support of this work.=C2=A0

Cheers,
Rober= t.


On Tue, Aug 23, 2016 at 2:08 P= M, Christoph Loibl <c@tix.at> wrote:
https://datatracker.i= etf.org/doc/draft-loibl-bacher-idr-flowspec-clarification/
The reason for this draft submission is, that we recently performed a rathe= r large flowspec interop test (the main goal was to evaluate possible inter= -AS flowspec scenarios in a multi vendor environment) and discovered many b= ugs and vendor interop problems that we want to solve.

Unfortunately we currently cannot share all our findings in a test report, = because we hit some serious bugs that have (under circumstances) potential = to remotely melt down entire networks and are working with the vendors to g= et bugs fixed.

Christoph

--
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C005= 5 | http://www.nextlayer.at


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr


--001a114eafecab48e8053abca8e1-- From nobody Tue Aug 23 07:18:18 2016 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 DA66D12DA32 for ; Tue, 23 Aug 2016 07:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 Nw4Zf811Xj1l for ; Tue, 23 Aug 2016 07:18:12 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5437112D9A4 for ; Tue, 23 Aug 2016 07:13:48 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u7NEA6dJ001521; Tue, 23 Aug 2016 10:13:47 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 250nhyspjw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Aug 2016 10:13:46 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u7NEDjUC017849; Tue, 23 Aug 2016 10:13:46 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u7NEDdx1017787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Aug 2016 10:13:42 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 23 Aug 2016 14:13:28 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.23]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0301.000; Tue, 23 Aug 2016 10:13:28 -0400 From: "UTTARO, JAMES" To: Christoph Loibl , "idr@ietf.org" Thread-Topic: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification Thread-Index: AQHR/TcvLjIyYQIeSECCnbqT6u78PqBWk4Og Date: Tue, 23 Aug 2016 14:13:27 +0000 Message-ID: References: <65345B6C-D24F-4F32-BF3C-E9343A7C61E1@tix.at> In-Reply-To: <65345B6C-D24F-4F32-BF3C-E9343A7C61E1@tix.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-23_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608230142 Archived-At: Subject: Re: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 14:18:17 -0000 Christoph, One could also us flow-spec as a mechanism to disseminate flow-spec "filte= rs" via an SDN controller. I am my co-authors specified changes to the vali= dation procedure such that the unicast route is not required for a router t= o accept and program the slow-spec path/filter. When reading through the d= raft it seems to assume that flow-spec is only used as originally intended = this is not the case. IMO this is a good piece of work and it should broade= n the scope to include how flow-spec can be used from an SDN Controller.. T= here are other challenges with the draft as originally written - Order of Traffic Filtering Rules - More specific unicast routes - AS value position in the AS-Path Here is the draft.. https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-03=20 Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christoph Loibl Sent: Tuesday, August 23, 2016 8:09 AM To: idr@ietf.org Subject: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarifi= cation Hi, We submitted a new draft and are happy to receive feedback: Since interoperability is key to an flowspec Internet deployment we tried t= o clarify the ambiguous parts of the flowspec RFC 5575 in order to allow a = consistent implementation by equipment vendors. Title: draft-loibl-bacher-idr-flowspec-clarification https://datatracker.ietf.org/doc/draft-loibl-bacher-idr-flowspec-clarificat= ion/ The reason for this draft submission is, that we recently performed a rathe= r large flowspec interop test (the main goal was to evaluate possible inter= -AS flowspec scenarios in a multi vendor environment) and discovered many b= ugs and vendor interop problems that we want to solve. Unfortunately we currently cannot share all our findings in a test report, = because we hit some serious bugs that have (under circumstances) potential = to remotely melt down entire networks and are working with the vendors to g= et bugs fixed. Christoph -- Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at From nobody Tue Aug 23 07:48:05 2016 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 EA30412DA15 for ; Tue, 23 Aug 2016 07:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7MKN0acabWZU for ; Tue, 23 Aug 2016 07:47:58 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 316D512DA17 for ; Tue, 23 Aug 2016 07:28:16 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id v123so107867178qkh.2 for ; Tue, 23 Aug 2016 07:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rNedad3AUiZD018uEHscDHIYJF8t7tcESDNuHqLY6IY=; b=E8v8z85vCBhBlby2efhdvC+RiQ08KPtMNkg5UlstWa2clBBPj6d+U5RzujtZxwAqT4 qoTHM6rAbUcvNGuFvb7jGH+Diyg40JaTI/pC+AvGcC9ErzXrgFcqUgifZqlms/ygQzCo iV2CzEEvcX+7AaggQS1rLL/SXdWIHjFK2j/dhysImYEzJ0vTilsA7En8Cus3t+mCWxjh rkjEayPN3SCMQbywQ9LgiS6EqQeW1dpgcZcts304trXfREZbhfGWxDkoYJ438mrhc7Eo J74oo4QH7HfD6bCcyWIlo9A0G76Y3sFQeWrPR3cbl8oBMedm4c/wpuxpWlGtn4YvFVoA rvoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rNedad3AUiZD018uEHscDHIYJF8t7tcESDNuHqLY6IY=; b=mRuRN+cd4Jbmhen2tBlS/ffI25UaLsdB2jOaBB2NhglrAyvhZ5NFKdtYxY/UlC+2g0 DpZAhZFdWoLUYiCvV6vTTgw0+YkWgGrZrdoVClkdZ5TML0baZxjwlxEpn3lVsWOhCeqi gJNDJnj+YZkNCdQhyJYHjHUJVpBsxqXvmcKeJp7WZD33gUxvDNLTpAsMjkIXd8xM0PaL /B7xLNNNvio82Na/tbuwp//oWWzk1nX4lTGH0gYpklpzh1zjAS5ha2cwdIXInFBlt2CF 9zOI9OFiRax16VVmO/1Sd+JPlyBjsXAD2Sd7SiOc3uwVMTP9u0DhVacnpGsXJrRR0fhe q+sw== X-Gm-Message-State: AE9vXwO31FS1aJnoMwIt2hlPD4yh5QWR0Z+g8X1G9T1ADVEenIHa5lyKMZ5NL65I0qQOli0cmBrK4QvdZ9SzzQ== X-Received: by 10.55.127.1 with SMTP id a1mr29735226qkd.80.1471962495249; Tue, 23 Aug 2016 07:28:15 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.30.130 with HTTP; Tue, 23 Aug 2016 07:28:14 -0700 (PDT) In-Reply-To: References: <65345B6C-D24F-4F32-BF3C-E9343A7C61E1@tix.at> From: Robert Raszuk Date: Tue, 23 Aug 2016 16:28:14 +0200 X-Google-Sender-Auth: uboHSv0--7x0B7PtnW8XDqwPZbw Message-ID: To: "UTTARO, JAMES" Content-Type: multipart/alternative; boundary=94eb2c0665caa6f3a6053abdf9e5 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 14:48:03 -0000 --94eb2c0665caa6f3a6053abdf9e5 Content-Type: text/plain; charset=UTF-8 Hey Jim, Indeed I alluded to your and others contributions to generalize flowspec when I mentioned the intra-domain case. Even putting aside SDN use cases there still can be valid DDoS filters injected centrally - hence my comment. For your point however I (*still*) think it would be much easier and simpler to put all SDN and related work into Flowspec_v2 and run in in different SAFI. Yourself, Sue and bunch of other people are actively helping with. That v2 spec may have completely different validation rules or not have them at all assuming validation happens on controller only. IMHO mixing both quite separate use cases will not help each other at all deployment wise - even if both deployment models are very valid. The reason being that what knobs work for one flowspec NLRIs for the other could turn to be harmful. So if we do not separate them and someone would like to use both it will get pretty ugly soon. Cheers, R. On Tue, Aug 23, 2016 at 4:13 PM, UTTARO, JAMES wrote: > Christoph, > > One could also us flow-spec as a mechanism to disseminate > flow-spec "filters" via an SDN controller. I am my co-authors specified > changes to the validation procedure such that the unicast route is not > required for a router to accept and program the slow-spec path/filter. > When reading through the draft it seems to assume that flow-spec is only > used as originally intended this is not the case. IMO this is a good piece > of work and it should broaden the scope to include how flow-spec can be > used from an SDN Controller.. There are other challenges with the draft as > originally written > > - Order of Traffic Filtering Rules > - More specific unicast routes > - AS value position in the AS-Path > > Here is the draft.. > > https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-03 > > Jim Uttaro > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Christoph Loibl > Sent: Tuesday, August 23, 2016 8:09 AM > To: idr@ietf.org > Subject: [Idr] New draft submitted: draft-loibl-bacher-idr- > flowspec-clarification > > Hi, > > We submitted a new draft and are happy to receive feedback: > > Since interoperability is key to an flowspec Internet deployment we tried > to clarify the ambiguous parts of the flowspec RFC 5575 in order to allow a > consistent implementation by equipment vendors. > > Title: draft-loibl-bacher-idr-flowspec-clarification > > https://datatracker.ietf.org/doc/draft-loibl-bacher-idr- > flowspec-clarification/ > > The reason for this draft submission is, that we recently performed a > rather large flowspec interop test (the main goal was to evaluate possible > inter-AS flowspec scenarios in a multi vendor environment) and discovered > many bugs and vendor interop problems that we want to solve. > > Unfortunately we currently cannot share all our findings in a test report, > because we hit some serious bugs that have (under circumstances) potential > to remotely melt down entire networks and are working with the vendors to > get bugs fixed. > > Christoph > > -- > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --94eb2c0665caa6f3a6053abdf9e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Jim,

Indeed I alluded to your and others contributions to= generalize flowspec when I mentioned the intra-domain case. Even putting a= side SDN use cases there still can be valid DDoS filters injected centrally= - hence my comment.=C2=A0

For your point however I (*still*) think it would be much easier and s= impler to put all SDN and related work into Flowspec_v2 and run in in diffe= rent SAFI. Yourself, Sue and bunch of other people are actively helping wit= h. That v2 spec may have completely different validation rules or not have = them at all assuming validation happens on controller only.=C2=A0

IMHO mixing both quite separate= use cases will not help each other at all deployment wise - even if both d= eployment models are very valid. The reason being that what knobs work for = one flowspec NLRIs for the other could turn to be harmful. So if we do not = separate them and someone would like to use both it will get pretty ugly so= on.

Cheers,
R.



On Tue, Aug 23, 2016 at 4:1= 3 PM, UTTARO, JAMES <ju1738@att.com> wrote:
Christoph,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 One could also us flow-spec as a mechanism to d= isseminate flow-spec "filters" via an SDN controller. I am my co-= authors specified changes to the validation procedure such that the unicast= route is not required for a router to accept and program the slow-spec pat= h/filter.=C2=A0 When reading through the draft it seems to assume that flow= -spec is only used as originally intended this is not the case. IMO this is= a good piece of work and it should broaden the scope to include how flow-s= pec can be used from an SDN Controller.. There are other challenges with th= e draft as originally written

- Order of Traffic Filtering Rules
- More specific unicast routes
- AS value position in the AS-Path

Here is the draft..

https://tools.ietf.org/html/draft= -ietf-idr-bgp-flowspec-oid-03

Jim Uttaro

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.= org] On Behalf Of Christoph Loibl
Sent: Tuesday, August 23, 2016 8:09 AM
To: idr@ietf.org
Subject: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-cl= arification

Hi,

We submitted a new draft and are happy to receive feedback:

Since interoperability is key to an flowspec Internet deployment we tried t= o clarify the ambiguous parts of the flowspec RFC 5575 in order to allow a = consistent implementation by equipment vendors.

Title: draft-loibl-bacher-idr-flowspec-clarification

https://datatracker.i= etf.org/doc/draft-loibl-bacher-idr-flowspec-clarification/
The reason for this draft submission is, that we recently performed a rathe= r large flowspec interop test (the main goal was to evaluate possible inter= -AS flowspec scenarios in a multi vendor environment) and discovered many b= ugs and vendor interop problems that we want to solve.

Unfortunately we currently cannot share all our findings in a test report, = because we hit some serious bugs that have (under circumstances) potential = to remotely melt down entire networks and are working with the vendors to g= et bugs fixed.

Christoph

--
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C005= 5 | http://www.nextlayer.at

_______________________= ________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--94eb2c0665caa6f3a6053abdf9e5-- From nobody Tue Aug 23 07:50:35 2016 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 1AFA112D0F7 for ; Tue, 23 Aug 2016 07:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 MxAun3wREupl for ; Tue, 23 Aug 2016 07:50:29 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A85312DB23 for ; Tue, 23 Aug 2016 07:29:57 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u7NENrmB042930; Tue, 23 Aug 2016 10:29:56 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 250qkkuu6t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Aug 2016 10:29:56 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u7NETsAE016431; Tue, 23 Aug 2016 10:29:55 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u7NETlgt016243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Aug 2016 10:29:50 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 23 Aug 2016 14:29:36 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.23]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0301.000; Tue, 23 Aug 2016 10:29:36 -0400 From: "UTTARO, JAMES" To: Robert Raszuk Thread-Topic: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification Thread-Index: AQHR/UqZj5zkcYA/zkaBJNJwgXsDTaBWmtqg Date: Tue, 23 Aug 2016 14:29:35 +0000 Message-ID: References: <65345B6C-D24F-4F32-BF3C-E9343A7C61E1@tix.at> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.251] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F1FF1FF3BMISOUT7MSGUSRCD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-23_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608230144 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 14:50:34 -0000 --_000_B17A6910EEDD1F45980687268941550F1FF1FF3BMISOUT7MSGUSRCD_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQogICAgICAgICAgICAgICAgTWFrZXMgc2Vuc2UuLg0KDQpUaGFua3MsDQogICAg ICAgICAgICAgICAgSmltIFV0dGFybw0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRv OnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVHVl c2RheSwgQXVndXN0IDIzLCAyMDE2IDEwOjI4IEFNDQpUbzogVVRUQVJPLCBKQU1FUyA8anUxNzM4 QGF0dC5jb20+DQpDYzogQ2hyaXN0b3BoIExvaWJsIDxjQHRpeC5hdD47IGlkckBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtJZHJdIE5ldyBkcmFmdCBzdWJtaXR0ZWQ6IGRyYWZ0LWxvaWJsLWJhY2hl ci1pZHItZmxvd3NwZWMtY2xhcmlmaWNhdGlvbg0KDQpIZXkgSmltLA0KDQpJbmRlZWQgSSBhbGx1 ZGVkIHRvIHlvdXIgYW5kIG90aGVycyBjb250cmlidXRpb25zIHRvIGdlbmVyYWxpemUgZmxvd3Nw ZWMgd2hlbiBJIG1lbnRpb25lZCB0aGUgaW50cmEtZG9tYWluIGNhc2UuIEV2ZW4gcHV0dGluZyBh c2lkZSBTRE4gdXNlIGNhc2VzIHRoZXJlIHN0aWxsIGNhbiBiZSB2YWxpZCBERG9TIGZpbHRlcnMg aW5qZWN0ZWQgY2VudHJhbGx5IC0gaGVuY2UgbXkgY29tbWVudC4NCg0KRm9yIHlvdXIgcG9pbnQg aG93ZXZlciBJICgqc3RpbGwqKSB0aGluayBpdCB3b3VsZCBiZSBtdWNoIGVhc2llciBhbmQgc2lt cGxlciB0byBwdXQgYWxsIFNETiBhbmQgcmVsYXRlZCB3b3JrIGludG8gRmxvd3NwZWNfdjIgYW5k IHJ1biBpbiBpbiBkaWZmZXJlbnQgU0FGSS4gWW91cnNlbGYsIFN1ZSBhbmQgYnVuY2ggb2Ygb3Ro ZXIgcGVvcGxlIGFyZSBhY3RpdmVseSBoZWxwaW5nIHdpdGguIFRoYXQgdjIgc3BlYyBtYXkgaGF2 ZSBjb21wbGV0ZWx5IGRpZmZlcmVudCB2YWxpZGF0aW9uIHJ1bGVzIG9yIG5vdCBoYXZlIHRoZW0g YXQgYWxsIGFzc3VtaW5nIHZhbGlkYXRpb24gaGFwcGVucyBvbiBjb250cm9sbGVyIG9ubHkuDQoN CklNSE8gbWl4aW5nIGJvdGggcXVpdGUgc2VwYXJhdGUgdXNlIGNhc2VzIHdpbGwgbm90IGhlbHAg ZWFjaCBvdGhlciBhdCBhbGwgZGVwbG95bWVudCB3aXNlIC0gZXZlbiBpZiBib3RoIGRlcGxveW1l bnQgbW9kZWxzIGFyZSB2ZXJ5IHZhbGlkLiBUaGUgcmVhc29uIGJlaW5nIHRoYXQgd2hhdCBrbm9i cyB3b3JrIGZvciBvbmUgZmxvd3NwZWMgTkxSSXMgZm9yIHRoZSBvdGhlciBjb3VsZCB0dXJuIHRv IGJlIGhhcm1mdWwuIFNvIGlmIHdlIGRvIG5vdCBzZXBhcmF0ZSB0aGVtIGFuZCBzb21lb25lIHdv dWxkIGxpa2UgdG8gdXNlIGJvdGggaXQgd2lsbCBnZXQgcHJldHR5IHVnbHkgc29vbi4NCg0KQ2hl ZXJzLA0KUi4NCg0KDQoNCk9uIFR1ZSwgQXVnIDIzLCAyMDE2IGF0IDQ6MTMgUE0sIFVUVEFSTywg SkFNRVMgPGp1MTczOEBhdHQuY29tPG1haWx0bzpqdTE3MzhAYXR0LmNvbT4+IHdyb3RlOg0KQ2hy aXN0b3BoLA0KDQogICAgICAgIE9uZSBjb3VsZCBhbHNvIHVzIGZsb3ctc3BlYyBhcyBhIG1lY2hh bmlzbSB0byBkaXNzZW1pbmF0ZSBmbG93LXNwZWMgImZpbHRlcnMiIHZpYSBhbiBTRE4gY29udHJv bGxlci4gSSBhbSBteSBjby1hdXRob3JzIHNwZWNpZmllZCBjaGFuZ2VzIHRvIHRoZSB2YWxpZGF0 aW9uIHByb2NlZHVyZSBzdWNoIHRoYXQgdGhlIHVuaWNhc3Qgcm91dGUgaXMgbm90IHJlcXVpcmVk IGZvciBhIHJvdXRlciB0byBhY2NlcHQgYW5kIHByb2dyYW0gdGhlIHNsb3ctc3BlYyBwYXRoL2Zp bHRlci4gIFdoZW4gcmVhZGluZyB0aHJvdWdoIHRoZSBkcmFmdCBpdCBzZWVtcyB0byBhc3N1bWUg dGhhdCBmbG93LXNwZWMgaXMgb25seSB1c2VkIGFzIG9yaWdpbmFsbHkgaW50ZW5kZWQgdGhpcyBp cyBub3QgdGhlIGNhc2UuIElNTyB0aGlzIGlzIGEgZ29vZCBwaWVjZSBvZiB3b3JrIGFuZCBpdCBz aG91bGQgYnJvYWRlbiB0aGUgc2NvcGUgdG8gaW5jbHVkZSBob3cgZmxvdy1zcGVjIGNhbiBiZSB1 c2VkIGZyb20gYW4gU0ROIENvbnRyb2xsZXIuLiBUaGVyZSBhcmUgb3RoZXIgY2hhbGxlbmdlcyB3 aXRoIHRoZSBkcmFmdCBhcyBvcmlnaW5hbGx5IHdyaXR0ZW4NCg0KLSBPcmRlciBvZiBUcmFmZmlj IEZpbHRlcmluZyBSdWxlcw0KLSBNb3JlIHNwZWNpZmljIHVuaWNhc3Qgcm91dGVzDQotIEFTIHZh bHVlIHBvc2l0aW9uIGluIHRoZSBBUy1QYXRoDQoNCkhlcmUgaXMgdGhlIGRyYWZ0Li4NCg0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1mbG93c3BlYy1vaWQt MDMNCg0KSmltIFV0dGFybw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSWRy IFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3Jn Pl0gT24gQmVoYWxmIE9mIENocmlzdG9waCBMb2libA0KU2VudDogVHVlc2RheSwgQXVndXN0IDIz LCAyMDE2IDg6MDkgQU0NClRvOiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4NClN1 YmplY3Q6IFtJZHJdIE5ldyBkcmFmdCBzdWJtaXR0ZWQ6IGRyYWZ0LWxvaWJsLWJhY2hlci1pZHIt Zmxvd3NwZWMtY2xhcmlmaWNhdGlvbg0KDQpIaSwNCg0KV2Ugc3VibWl0dGVkIGEgbmV3IGRyYWZ0 IGFuZCBhcmUgaGFwcHkgdG8gcmVjZWl2ZSBmZWVkYmFjazoNCg0KU2luY2UgaW50ZXJvcGVyYWJp bGl0eSBpcyBrZXkgdG8gYW4gZmxvd3NwZWMgSW50ZXJuZXQgZGVwbG95bWVudCB3ZSB0cmllZCB0 byBjbGFyaWZ5IHRoZSBhbWJpZ3VvdXMgcGFydHMgb2YgdGhlIGZsb3dzcGVjIFJGQyA1NTc1IGlu IG9yZGVyIHRvIGFsbG93IGEgY29uc2lzdGVudCBpbXBsZW1lbnRhdGlvbiBieSBlcXVpcG1lbnQg dmVuZG9ycy4NCg0KVGl0bGU6IGRyYWZ0LWxvaWJsLWJhY2hlci1pZHItZmxvd3NwZWMtY2xhcmlm aWNhdGlvbg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb2libC1i YWNoZXItaWRyLWZsb3dzcGVjLWNsYXJpZmljYXRpb24vDQoNClRoZSByZWFzb24gZm9yIHRoaXMg ZHJhZnQgc3VibWlzc2lvbiBpcywgdGhhdCB3ZSByZWNlbnRseSBwZXJmb3JtZWQgYSByYXRoZXIg bGFyZ2UgZmxvd3NwZWMgaW50ZXJvcCB0ZXN0ICh0aGUgbWFpbiBnb2FsIHdhcyB0byBldmFsdWF0 ZSBwb3NzaWJsZSBpbnRlci1BUyBmbG93c3BlYyBzY2VuYXJpb3MgaW4gYSBtdWx0aSB2ZW5kb3Ig ZW52aXJvbm1lbnQpIGFuZCBkaXNjb3ZlcmVkIG1hbnkgYnVncyBhbmQgdmVuZG9yIGludGVyb3Ag cHJvYmxlbXMgdGhhdCB3ZSB3YW50IHRvIHNvbHZlLg0KDQpVbmZvcnR1bmF0ZWx5IHdlIGN1cnJl bnRseSBjYW5ub3Qgc2hhcmUgYWxsIG91ciBmaW5kaW5ncyBpbiBhIHRlc3QgcmVwb3J0LCBiZWNh dXNlIHdlIGhpdCBzb21lIHNlcmlvdXMgYnVncyB0aGF0IGhhdmUgKHVuZGVyIGNpcmN1bXN0YW5j ZXMpIHBvdGVudGlhbCB0byByZW1vdGVseSBtZWx0IGRvd24gZW50aXJlIG5ldHdvcmtzIGFuZCBh cmUgd29ya2luZyB3aXRoIHRoZSB2ZW5kb3JzIHRvIGdldCBidWdzIGZpeGVkLg0KDQpDaHJpc3Rv cGgNCg0KLS0NCkNocmlzdG9waCBMb2libA0KY0B0aXguYXQ8bWFpbHRvOmNAdGl4LmF0PiB8IENM OC1SSVBFIHwgUEdQLUtleS1JRDogMHg0QjJDMDA1NSB8IGh0dHA6Ly93d3cubmV4dGxheWVyLmF0 DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1h aWxpbmcgbGlzdA0KSWRyQGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0KDQo= --_000_B17A6910EEDD1F45980687268941550F1FF1FF3BMISOUT7MSGUSRCD_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojNDQ1NDZBOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7DQoJZm9udC1z dHlsZTppdGFsaWM7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj5Sb2JlcnQs PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NTQ2QSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzQ0NTQ2QSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1ha2VzIHNl bnNlLi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM0NDU0NkEiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1 NDZBIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSmltIFV0dGFybzxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVr QGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMjMsIDIwMTYgMTA6MjggQU08YnI+DQo8Yj5Ubzo8L2I+ IFVUVEFSTywgSkFNRVMgJmx0O2p1MTczOEBhdHQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQ2hy aXN0b3BoIExvaWJsICZsdDtjQHRpeC5hdCZndDs7IGlkckBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW0lkcl0gTmV3IGRyYWZ0IHN1Ym1pdHRlZDogZHJhZnQtbG9pYmwtYmFjaGVy LWlkci1mbG93c3BlYy1jbGFyaWZpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5IZXkgSmltLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SW5kZWVkIEkgYWxsdWRlZCB0byB5b3VyIGFu ZCBvdGhlcnMgY29udHJpYnV0aW9ucyB0byBnZW5lcmFsaXplIGZsb3dzcGVjIHdoZW4gSSBtZW50 aW9uZWQgdGhlIGludHJhLWRvbWFpbiBjYXNlLiBFdmVuIHB1dHRpbmcgYXNpZGUgU0ROIHVzZSBj YXNlcyB0aGVyZSBzdGlsbCBjYW4gYmUgdmFsaWQgRERvUyBmaWx0ZXJzIGluamVjdGVkDQogY2Vu dHJhbGx5IC0gaGVuY2UgbXkgY29tbWVudC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkZvciB5b3VyIHBvaW50IGhv d2V2ZXIgSSAoKnN0aWxsKikgdGhpbmsgaXQgd291bGQgYmUgbXVjaCBlYXNpZXIgYW5kIHNpbXBs ZXIgdG8gcHV0IGFsbCBTRE4gYW5kIHJlbGF0ZWQgd29yayBpbnRvIEZsb3dzcGVjX3YyIGFuZCBy dW4gaW4gaW4gZGlmZmVyZW50IFNBRkkuIFlvdXJzZWxmLCBTdWUgYW5kIGJ1bmNoIG9mIG90aGVy IHBlb3BsZQ0KIGFyZSBhY3RpdmVseSBoZWxwaW5nIHdpdGguIFRoYXQgdjIgc3BlYyBtYXkgaGF2 ZSBjb21wbGV0ZWx5IGRpZmZlcmVudCB2YWxpZGF0aW9uIHJ1bGVzIG9yIG5vdCBoYXZlIHRoZW0g YXQgYWxsIGFzc3VtaW5nIHZhbGlkYXRpb24gaGFwcGVucyBvbiBjb250cm9sbGVyIG9ubHkuJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5JTUhPIG1peGluZyBib3RoIHF1aXRlIHNlcGFyYXRlIHVzZSBjYXNlcyB3aWxs IG5vdCBoZWxwIGVhY2ggb3RoZXIgYXQgYWxsIGRlcGxveW1lbnQgd2lzZSAtIGV2ZW4gaWYgYm90 aCBkZXBsb3ltZW50IG1vZGVscyBhcmUgdmVyeSB2YWxpZC4gVGhlIHJlYXNvbiBiZWluZyB0aGF0 IHdoYXQga25vYnMgd29yayBmb3Igb25lIGZsb3dzcGVjDQogTkxSSXMgZm9yIHRoZSBvdGhlciBj b3VsZCB0dXJuIHRvIGJlIGhhcm1mdWwuIFNvIGlmIHdlIGRvIG5vdCBzZXBhcmF0ZSB0aGVtIGFu ZCBzb21lb25lIHdvdWxkIGxpa2UgdG8gdXNlIGJvdGggaXQgd2lsbCBnZXQgcHJldHR5IHVnbHkg c29vbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPkNoZWVycyw8YnI+DQpSLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1 ZyAyMywgMjAxNiBhdCA0OjEzIFBNLCBVVFRBUk8sIEpBTUVTICZsdDs8YSBocmVmPSJtYWlsdG86 anUxNzM4QGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj5qdTE3MzhAYXR0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNo cmlzdG9waCw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT25lIGNvdWxk IGFsc28gdXMgZmxvdy1zcGVjIGFzIGEgbWVjaGFuaXNtIHRvIGRpc3NlbWluYXRlIGZsb3ctc3Bl YyAmcXVvdDtmaWx0ZXJzJnF1b3Q7IHZpYSBhbiBTRE4gY29udHJvbGxlci4gSSBhbSBteSBjby1h dXRob3JzIHNwZWNpZmllZCBjaGFuZ2VzIHRvIHRoZSB2YWxpZGF0aW9uIHByb2NlZHVyZSBzdWNo IHRoYXQgdGhlIHVuaWNhc3Qgcm91dGUgaXMgbm90IHJlcXVpcmVkIGZvciBhIHJvdXRlciB0byBh Y2NlcHQgYW5kIHByb2dyYW0gdGhlDQogc2xvdy1zcGVjIHBhdGgvZmlsdGVyLiZuYnNwOyBXaGVu IHJlYWRpbmcgdGhyb3VnaCB0aGUgZHJhZnQgaXQgc2VlbXMgdG8gYXNzdW1lIHRoYXQgZmxvdy1z cGVjIGlzIG9ubHkgdXNlZCBhcyBvcmlnaW5hbGx5IGludGVuZGVkIHRoaXMgaXMgbm90IHRoZSBj YXNlLiBJTU8gdGhpcyBpcyBhIGdvb2QgcGllY2Ugb2Ygd29yayBhbmQgaXQgc2hvdWxkIGJyb2Fk ZW4gdGhlIHNjb3BlIHRvIGluY2x1ZGUgaG93IGZsb3ctc3BlYyBjYW4gYmUgdXNlZCBmcm9tIGFu DQogU0ROIENvbnRyb2xsZXIuLiBUaGVyZSBhcmUgb3RoZXIgY2hhbGxlbmdlcyB3aXRoIHRoZSBk cmFmdCBhcyBvcmlnaW5hbGx5IHdyaXR0ZW48YnI+DQo8YnI+DQotIE9yZGVyIG9mIFRyYWZmaWMg RmlsdGVyaW5nIFJ1bGVzPGJyPg0KLSBNb3JlIHNwZWNpZmljIHVuaWNhc3Qgcm91dGVzPGJyPg0K LSBBUyB2YWx1ZSBwb3NpdGlvbiBpbiB0aGUgQVMtUGF0aDxicj4NCjxicj4NCkhlcmUgaXMgdGhl IGRyYWZ0Li48YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1pZHItYmdwLWZsb3dzcGVjLW9pZC0wMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtZmxvd3NwZWMtb2lkLTAz PC9hPjxicj4NCjxicj4NCkppbSBVdHRhcm88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IElkciBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP biBCZWhhbGYgT2YgQ2hyaXN0b3BoIExvaWJsPGJyPg0KU2VudDogVHVlc2RheSwgQXVndXN0IDIz LCAyMDE2IDg6MDkgQU08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRy QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFtJZHJdIE5ldyBkcmFmdCBzdWJtaXR0ZWQ6IGRy YWZ0LWxvaWJsLWJhY2hlci1pZHItZmxvd3NwZWMtY2xhcmlmaWNhdGlvbjxicj4NCjxicj4NCkhp LDxicj4NCjxicj4NCldlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBhbmQgYXJlIGhhcHB5IHRvIHJl Y2VpdmUgZmVlZGJhY2s6PGJyPg0KPGJyPg0KU2luY2UgaW50ZXJvcGVyYWJpbGl0eSBpcyBrZXkg dG8gYW4gZmxvd3NwZWMgSW50ZXJuZXQgZGVwbG95bWVudCB3ZSB0cmllZCB0byBjbGFyaWZ5IHRo ZSBhbWJpZ3VvdXMgcGFydHMgb2YgdGhlIGZsb3dzcGVjIFJGQyA1NTc1IGluIG9yZGVyIHRvIGFs bG93IGEgY29uc2lzdGVudCBpbXBsZW1lbnRhdGlvbiBieSBlcXVpcG1lbnQgdmVuZG9ycy48YnI+ DQo8YnI+DQpUaXRsZTogZHJhZnQtbG9pYmwtYmFjaGVyLWlkci1mbG93c3BlYy1jbGFyaWZpY2F0 aW9uPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbG9pYmwtYmFjaGVyLWlkci1mbG93c3BlYy1jbGFyaWZpY2F0aW9uLyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxvaWJsLWJhY2hl ci1pZHItZmxvd3NwZWMtY2xhcmlmaWNhdGlvbi88L2E+PGJyPg0KPGJyPg0KVGhlIHJlYXNvbiBm b3IgdGhpcyBkcmFmdCBzdWJtaXNzaW9uIGlzLCB0aGF0IHdlIHJlY2VudGx5IHBlcmZvcm1lZCBh IHJhdGhlciBsYXJnZSBmbG93c3BlYyBpbnRlcm9wIHRlc3QgKHRoZSBtYWluIGdvYWwgd2FzIHRv IGV2YWx1YXRlIHBvc3NpYmxlIGludGVyLUFTIGZsb3dzcGVjIHNjZW5hcmlvcyBpbiBhIG11bHRp IHZlbmRvciBlbnZpcm9ubWVudCkgYW5kIGRpc2NvdmVyZWQgbWFueSBidWdzIGFuZCB2ZW5kb3Ig aW50ZXJvcCBwcm9ibGVtcw0KIHRoYXQgd2Ugd2FudCB0byBzb2x2ZS48YnI+DQo8YnI+DQpVbmZv cnR1bmF0ZWx5IHdlIGN1cnJlbnRseSBjYW5ub3Qgc2hhcmUgYWxsIG91ciBmaW5kaW5ncyBpbiBh IHRlc3QgcmVwb3J0LCBiZWNhdXNlIHdlIGhpdCBzb21lIHNlcmlvdXMgYnVncyB0aGF0IGhhdmUg KHVuZGVyIGNpcmN1bXN0YW5jZXMpIHBvdGVudGlhbCB0byByZW1vdGVseSBtZWx0IGRvd24gZW50 aXJlIG5ldHdvcmtzIGFuZCBhcmUgd29ya2luZyB3aXRoIHRoZSB2ZW5kb3JzIHRvIGdldCBidWdz IGZpeGVkLjxicj4NCjxicj4NCkNocmlzdG9waDxicj4NCjxicj4NCi0tPGJyPg0KQ2hyaXN0b3Bo IExvaWJsPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmNAdGl4LmF0Ij5jQHRpeC5hdDwvYT4gfCBDTDgt UklQRSB8IFBHUC1LZXktSUQ6IDB4NEIyQzAwNTUgfCA8YSBocmVmPSJodHRwOi8vd3d3Lm5leHRs YXllci5hdCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5uZXh0bGF5ZXIuYXQ8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCklkciBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWRyQGlldGYub3JnIj5J ZHJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pZHIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B17A6910EEDD1F45980687268941550F1FF1FF3BMISOUT7MSGUSRCD_-- From nobody Wed Aug 24 03:11:55 2016 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 EDF9C12D8A0 for ; Wed, 24 Aug 2016 03:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 fvE-R65uSCiD for ; Wed, 24 Aug 2016 03:11:51 -0700 (PDT) Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7047312B034 for ; Wed, 24 Aug 2016 03:11:51 -0700 (PDT) Received: from [92.60.6.198] (helo=[10.55.3.175]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1bcV2x-0003Ob-U1; Wed, 24 Aug 2016 12:04:36 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9A670E5F-F2AD-469E-81EE-980AA5B9668B"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Christoph Loibl In-Reply-To: Date: Wed, 24 Aug 2016 12:11:42 +0200 Message-Id: References: <65345B6C-D24F-4F32-BF3C-E9343A7C61E1@tix.at> To: Robert Raszuk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: idr wg Subject: Re: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 10:11:54 -0000 --Apple-Mail=_9A670E5F-F2AD-469E-81EE-980AA5B9668B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Robert and James, Thank you for your comments and support on our document. I completely understand that the verification described in the RFC 5575 = is has certain limitations. Most current installations (at least that I = know of) are intra-AS _only_ and verification is completely disabled in = that case. I think that a relaxed / different validation than defined in = RFC 5575 makes perfectly sense in many ways. However, the primary intention of our draft is to clarify aspects that = are somehow ambiguous in RFC 5575. We tried to introduce only minimal = changes to the RFC (wherever possible) and fill gaps wherever clear = definitions were missing to allow a consistent implementation. Section 5 (revalidation) actually does not really introduce any = different behaviour to RFC 5575 it is basically a more verbose rewrite. = The reason why we still put into the draft is the following: During DDoS mitigations it is perfectly feasible that announcements of = prefixes change. Traffic steering/engineering may require to isolate = traffic via more-specific routes on certain AS-borders, IPv4 routes may = simply change during that process. For example: In our lab we saw = routers announcing the flow-spec NLRI before announcing the actual IPv4 = prefix during such route changes. So the flow-spec verification failed. = However, just 10ms later the IPv4 prefix was announced to that = particular neighbour (the flow-spec NLRI was still not taken into = account, because no revalidation took place). If there is no = revalidation of the flow-spec NLRI we end up with a completely = unpredictable verification that is based on the arrival time of the two = different NLRI announcements (IPv4 vs Flowspec) (some kind of race = condition). We may still decide to have a different verification mechanism in place = (as proposed by both of you) but the key here is, that it should always = result in a consistent/predictable view over the entire participating = networks. In my opinion the time of arrival of announcements should not = have any impact on the verification state of the rules. Cheers, Christoph -- Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at --Apple-Mail=_9A670E5F-F2AD-469E-81EE-980AA5B9668B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAle9cuEACgkQ0m2Mp0ssAFUe+gCfXDxznu0T8Z1+L1KGli4JwYdY D3YAoLP4XrJ+fD9El0YbtM75/+Ib6h4H =NfEP -----END PGP SIGNATURE----- --Apple-Mail=_9A670E5F-F2AD-469E-81EE-980AA5B9668B-- From nobody Wed Aug 24 04:31:04 2016 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 760AC12D123 for ; Wed, 24 Aug 2016 04:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zuu6c20uRb9p for ; Wed, 24 Aug 2016 04:31:01 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 1C3E412D098 for ; Wed, 24 Aug 2016 04:31:01 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z190so11399120qkc.0 for ; Wed, 24 Aug 2016 04:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qZZGSvbPtJtOkMx7TOZ4bkp5VWQxAHrVG7qVFGYD0O0=; b=dnkG9lJSW01pPYD0C/3VS/4EsY8su1iLcWefTkRA2j1H8mKYHj/kTDMxvhno3HD2GS RSpmg7my0G6nUL6zVO1EWS/yF9WsdC1IZtFP3ctm4ggYxF+t+N7omxIukf15cctPfI1o kCN8QCWnIhrxBqSHCk3Ro+fe/qr4tRauC0z9ie6l6W83M+qo9tVecoi9dK4dQZZetzEe 4JtLMKpUUIJeN6Yf4ODHc7axjQEtVoGDwIXb3zWOyDWWFWhdvebxZxdXGuonxfOc6po0 LhLAGph0lpYuOvyydgDY7fDGRHHlsWXVxxlTVNLbkh8riOGUmA6P1l9J57SJIHBX9Zis F0Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qZZGSvbPtJtOkMx7TOZ4bkp5VWQxAHrVG7qVFGYD0O0=; b=f1zBcHGPr9Sgnx9xNH494KB9v+lvQyLXb4fMO69txdQNuPq0k1UaAcZb6JxiQuuqmh h2nurn+XCLj9a2poL3XDPNunKRc097QR+BjbbzmMsQV7xckP4HSHht33BBLmoDtOoSTC wgSiigEStJRiyk6pfV5kxLN7e9R5MhnweaO+SEpn07YpblDUJahsaKdZQHumPyEtznIm mecccM3hIg5WhGgcF5RId6X4iiq0QBKY4TKBZ07ec36V8JimNA9PCRXS9VzocRPpZPBl HH4lMznEv3dmfbgyaTKmKj0/QopyPKpwlqkpqOv90/8j4T5r5jJj6+e8ieYx+qPgVsWh xc8A== X-Gm-Message-State: AE9vXwOfqZX1g/KN9GOpDS/n6M7c9gXPSn0lMI5Vt5aJhTI17xU+/rfrg77iHcmv9F4rwZ2LJBomTzzjAJnSzw== X-Received: by 10.55.93.71 with SMTP id r68mr2842124qkb.131.1472038259968; Wed, 24 Aug 2016 04:30:59 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.140.30.130 with HTTP; Wed, 24 Aug 2016 04:30:59 -0700 (PDT) In-Reply-To: References: <65345B6C-D24F-4F32-BF3C-E9343A7C61E1@tix.at> From: Robert Raszuk Date: Wed, 24 Aug 2016 13:30:59 +0200 X-Google-Sender-Auth: ADGkGvOf13lL09W8j7mk2g6bTj0 Message-ID: To: Christoph Loibl Content-Type: multipart/alternative; boundary=001a114d3e2a94d507053acf9d76 Archived-At: Cc: idr wg Subject: Re: [Idr] New draft submitted: draft-loibl-bacher-idr-flowspec-clarification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 11:31:03 -0000 --001a114d3e2a94d507053acf9d76 Content-Type: text/plain; charset=UTF-8 Hi, Well indeed the validation procedure or rather the decision may get quite complex. Just as an example - assume you are transit AS and you are peering towards two transit ASes. One of your peers sent you a flowspec route and the other did not. So my point was that even if best path changes the other AS will still get the attack as such will be rather part of the ACL towards the former AS. If we have unicast best path changes often and flow-spec NLRI are not withdrawn I would rather think more optimal is to keep the filter in the ACL if it was ever valid till it get's withdrawn. And for sure you or someone else may come with different scenario - say where you are switching best path and origin AS is different as the end victim is dual homed and has private AS. But even here maybe keeping the filter in place may help to save the victim. Lastly ... some folks may have already very heavy ACLs. Adding and removing the entries frequently especially on distributed switching platforms may constitute a problem. But in any case I was just trying to shed a bit of different perspective on it - that's all. Your draft is at least to me a very good quality work ! Cheers, R. On Wed, Aug 24, 2016 at 12:11 PM, Christoph Loibl wrote: > Dear Robert and James, > > Thank you for your comments and support on our document. > > I completely understand that the verification described in the RFC 5575 is > has certain limitations. Most current installations (at least that I know > of) are intra-AS _only_ and verification is completely disabled in that > case. I think that a relaxed / different validation than defined in RFC > 5575 makes perfectly sense in many ways. > > However, the primary intention of our draft is to clarify aspects that are > somehow ambiguous in RFC 5575. We tried to introduce only minimal changes > to the RFC (wherever possible) and fill gaps wherever clear definitions > were missing to allow a consistent implementation. > > Section 5 (revalidation) actually does not really introduce any different > behaviour to RFC 5575 it is basically a more verbose rewrite. The reason > why we still put into the draft is the following: > > During DDoS mitigations it is perfectly feasible that announcements of > prefixes change. Traffic steering/engineering may require to isolate > traffic via more-specific routes on certain AS-borders, IPv4 routes may > simply change during that process. For example: In our lab we saw routers > announcing the flow-spec NLRI before announcing the actual IPv4 prefix > during such route changes. So the flow-spec verification failed. However, > just 10ms later the IPv4 prefix was announced to that particular neighbour > (the flow-spec NLRI was still not taken into account, because no > revalidation took place). If there is no revalidation of the flow-spec NLRI > we end up with a completely unpredictable verification that is based on the > arrival time of the two different NLRI announcements (IPv4 vs Flowspec) > (some kind of race condition). > > We may still decide to have a different verification mechanism in place > (as proposed by both of you) but the key here is, that it should always > result in a consistent/predictable view over the entire participating > networks. In my opinion the time of arrival of announcements should not > have any impact on the verification state of the rules. > > Cheers, > Christoph > > -- > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > --001a114d3e2a94d507053acf9d76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">Well indeed the validation procedure or rather the decisi= on may get quite complex.=C2=A0

Just as an example - assume you are transit AS and you are peerin= g towards two transit ASes.=C2=A0

One of your peers sent you a flowspec route and the other did= not. So my point was that even if best path changes the other AS will stil= l get the attack as such will be rather part of the ACL towards the former = AS.=C2=A0

If we have u= nicast best path changes often and flow-spec NLRI are not withdrawn I would= rather think more optimal is to keep the filter in the ACL if it was ever = valid till it get's withdrawn.=C2=A0

=
And for sure you or someone else may come with different= scenario - say where you are switching best path and origin AS is differen= t as the end victim is dual homed and has private AS. But even here maybe k= eeping the filter in place may help to save the victim.=C2=A0

Lastly ... some folks may have alre= ady very heavy ACLs. Adding and removing the entries frequently especially = on distributed switching platforms may constitute a problem.=C2=A0

But in any case I was just try= ing to shed a bit of different perspective on it - that's all.

Your draft is at least to me a= very good quality work !

Cheers,
R.


=






On Wed, A= ug 24, 2016 at 12:11 PM, Christoph Loibl <c@tix.at> wrote:
Dear Robert and James,

Thank you for your comments and support on our document.

I completely understand that the verification described in the RFC 5575 is = has certain limitations. Most current installations (at least that I know o= f) are intra-AS _only_ and verification is completely disabled in that case= . I think that a relaxed / different validation than defined in RFC 5575 ma= kes perfectly sense in many ways.

However, the primary intention of our draft is to clarify aspects that are = somehow ambiguous in RFC 5575. We tried to introduce only minimal changes t= o the RFC (wherever possible) and fill gaps wherever clear definitions were= missing to allow a consistent implementation.

Section 5 (revalidation) actually does not really introduce any different b= ehaviour to RFC 5575 it is basically a more verbose rewrite. The reason why= we still put into the draft is the following:

During DDoS mitigations it is perfectly feasible that announcements of pref= ixes change. Traffic steering/engineering may require to isolate traffic vi= a more-specific routes on certain AS-borders, IPv4 routes may simply change= during that process. For example: In our lab we saw routers announcing the= flow-spec NLRI before announcing the actual IPv4 prefix during such route = changes. So the flow-spec verification failed. However, just 10ms later the= IPv4 prefix was announced to that particular neighbour (the flow-spec NLRI= was still not taken into account, because no revalidation took place). If = there is no revalidation of the flow-spec NLRI we end up with a completely = unpredictable verification that is based on the arrival time of the two dif= ferent NLRI announcements (IPv4 vs Flowspec) (some kind of race condition).=

We may still decide to have a different verification mechanism in place (as= proposed by both of you) but the key here is, that it should always result= in a consistent/predictable view over the entire participating networks. I= n my opinion the time of arrival of announcements should not have any impac= t on the verification state of the rules.

Cheers,
Christoph

--
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C005= 5 | http://www.nextlayer.at


--001a114d3e2a94d507053acf9d76-- From nobody Fri Aug 26 07:47:18 2016 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 28FF712D0A1 for ; Fri, 26 Aug 2016 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.856 X-Spam-Level: ** X-Spam-Status: No, score=2.856 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001] autolearn=no autolearn_force=no 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 Ih5k2w3oOnpV for ; Fri, 26 Aug 2016 07:47:12 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 8672912D09B for ; Fri, 26 Aug 2016 07:47:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Randy Bush'" , "'Keyur Patel \(keyupate\)'" , , Date: Fri, 26 Aug 2016 10:45:56 -0400 Message-ID: <096a01d1ffa8$8e0584d0$aa108e70$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_096B_01D1FF87.06F432F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdH/p/AIbQy4Rf9IQZmDrzebIdAvxQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IPR statement on draft-ietf-idr-extended-messages-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 14:47:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_096B_01D1FF87.06F432F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As authors of draft-ietf-idr-bgp-extended-messages-13, do you know of an IPR related to draft-ietf-idr-extended-messages-13.txt. I cannot forward this document to the IESG without your IPR statement posted to the idr@ietf.org list. Thank you, Susan Hares ------=_NextPart_000_096B_01D1FF87.06F432F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As authors = of draft-ietf-idr-bgp-extended-messages-13, do you know of an IPR = related to draft-ietf-idr-extended-messages-13.txt.   I cannot = forward this document to the IESG without your IPR statement posted to = the idr@ietf.org list. =   

 

Thank you,

Susan = Hares

------=_NextPart_000_096B_01D1FF87.06F432F0-- From nobody Fri Aug 26 12:55:34 2016 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 85AF012B063 for ; Fri, 26 Aug 2016 12:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 uIKcINUiyG6N for ; Fri, 26 Aug 2016 12:55:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 63E4312D74F for ; Fri, 26 Aug 2016 12:55:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bdNDq-0000J8-6j; Fri, 26 Aug 2016 19:55:26 +0000 Date: Sat, 27 Aug 2016 04:55:22 +0900 Message-ID: From: Randy Bush To: "Susan Hares" In-Reply-To: <096a01d1ffa8$8e0584d0$aa108e70$@ndzh.com> References: <096a01d1ffa8$8e0584d0$aa108e70$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr@ietf.org, Keyur Patel , dward@cisco.com Subject: Re: [Idr] IPR statement on draft-ietf-idr-extended-messages-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 19:55:32 -0000 > As authors of draft-ietf-idr-bgp-extended-messages-13, do you know of an IPR > related to draft-ietf-idr-extended-messages-13.txt. no randy From nobody Sat Aug 27 09:03:39 2016 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 4A3E912D0CA; Fri, 26 Aug 2016 08:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.856 X-Spam-Level: ** X-Spam-Status: No, score=2.856 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001] autolearn=no autolearn_force=no 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 BpZiCNTMbfAT; Fri, 26 Aug 2016 08:43:31 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 3554F127078; Fri, 26 Aug 2016 08:43:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: , Date: Fri, 26 Aug 2016 11:42:02 -0400 Message-ID: <09a501d1ffb0$64bed510$2e3c7f30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09A6_01D1FF8E.DDADF860" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdH/sEtACsmS79SBQDS9GkDBWMD0/w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Sat, 27 Aug 2016 09:03:37 -0700 Cc: "'Keyur Patel \(keyupate\)'" , robert.fragassi@alcatel-lucent.com, pmohapat@cumulusnetworks.com, 'Susan Hares' Subject: [Idr] IPR on draft-ietf-idr-add-paths-guidelines X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:43:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09A6_01D1FF8E.DDADF860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jim, Pierre, Pradosh, Robert, Adam, Keyur, and Jeff: Prior to submitting any document for publication of RFC, the shepherd must check the IPR. Would you please indicate (by responding to this email), if you know of any IPR related to draft-idr-add-paths-guidelines. I would appreciate if you respond to email so that the IPR declarations are stored in the IDR archive. Sue ------=_NextPart_000_09A6_01D1FF8E.DDADF860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim, = Pierre, Pradosh, Robert, Adam, Keyur, and Jeff:

 

Prior to = submitting any document for publication of RFC, the shepherd must check = the IPR.  Would you please indicate (by responding to this email), = if you know of any IPR related to = draft-idr-add-paths-guidelines.   I would appreciate if you = respond to email so that the IPR declarations are stored in the IDR = archive.

 

Sue

 

------=_NextPart_000_09A6_01D1FF8E.DDADF860-- From nobody Sat Aug 27 09:03:43 2016 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 8F16512D11B; Fri, 26 Aug 2016 08:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Cf855moD5WmJ; Fri, 26 Aug 2016 08:54:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5AB12D11A; Fri, 26 Aug 2016 08:54:06 -0700 (PDT) Received: from [172.29.35.228] (unknown [66.129.241.14]) by slice.pfrc.org (Postfix) with ESMTPSA id F1FAD1E1F0; Fri, 26 Aug 2016 11:54:38 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_154AF2E5-7F6D-4A86-A050-99D6595F8153" From: Jeffrey Haas In-Reply-To: <09a501d1ffb0$64bed510$2e3c7f30$@ndzh.com> Date: Fri, 26 Aug 2016 11:53:53 -0400 Message-Id: References: <09a501d1ffb0$64bed510$2e3c7f30$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Sat, 27 Aug 2016 09:03:37 -0700 Cc: idr@ietf.org, draft-ietf-idr-add-paths-guidelines@ietf.org, "Keyur Patel \(keyupate\)" , robert.fragassi@alcatel-lucent.com, pmohapat@cumulusnetworks.com Subject: Re: [Idr] IPR on draft-ietf-idr-add-paths-guidelines X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:54:07 -0000 --Apple-Mail=_154AF2E5-7F6D-4A86-A050-99D6595F8153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sue, Juniper asserts no IPR on the contents of add-paths-guidelines. -- Jeff > On Aug 26, 2016, at 11:42 AM, Susan Hares wrote: >=20 > Jim, Pierre, Pradosh, Robert, Adam, Keyur, and Jeff:=20 > =20 > Prior to submitting any document for publication of RFC, the shepherd = must check the IPR. Would you please indicate (by responding to this = email), if you know of any IPR related to = draft-idr-add-paths-guidelines. I would appreciate if you respond to = email so that the IPR declarations are stored in the IDR archive. > =20 > Sue=20 --Apple-Mail=_154AF2E5-7F6D-4A86-A050-99D6595F8153 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Sue,

Juniper asserts no IPR on the contents of = add-paths-guidelines.

-- Jeff

On Aug 26, 2016, at 11:42 AM, = Susan Hares <shares@ndzh.com> wrote:

Jim, = Pierre, Pradosh, Robert, Adam, Keyur, and Jeff: 
 
Prior to = submitting any document for publication of RFC, the shepherd must check = the IPR.  Would you please indicate (by responding to this email), = if you know of any IPR related to = draft-idr-add-paths-guidelines.   I would appreciate if you = respond to email so that the IPR declarations are stored in the IDR = archive.
 
Sue 

= --Apple-Mail=_154AF2E5-7F6D-4A86-A050-99D6595F8153-- From nobody Sat Aug 27 09:03:46 2016 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 3B4DC12D0C6; Fri, 26 Aug 2016 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 Z8fXakCulxl7; Fri, 26 Aug 2016 08:56:15 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCB012B065; Fri, 26 Aug 2016 08:56:14 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u7QFtfwE040498; Fri, 26 Aug 2016 11:56:12 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 252rdbh1js-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Aug 2016 11:56:12 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u7QFuAXF019040; Fri, 26 Aug 2016 11:56:11 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u7QFtwkH018789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Aug 2016 11:55:59 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 26 Aug 2016 15:55:48 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.23]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0301.000; Fri, 26 Aug 2016 11:55:47 -0400 From: "UTTARO, JAMES" To: Susan Hares , "idr@ietf.org" , "draft-ietf-idr-add-paths-guidelines@ietf.org" Thread-Topic: IPR on draft-ietf-idr-add-paths-guidelines Thread-Index: AdH/sEtACsmS79SBQDS9GkDBWMD0/wAAenDQ Date: Fri, 26 Aug 2016 15:55:47 +0000 Message-ID: References: <09a501d1ffb0$64bed510$2e3c7f30$@ndzh.com> In-Reply-To: <09a501d1ffb0$64bed510$2e3c7f30$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.208.82] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F1FF2140AMISOUT7MSGUSRCD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-26_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608260208 Archived-At: X-Mailman-Approved-At: Sat, 27 Aug 2016 09:03:37 -0700 Cc: "'Keyur Patel \(keyupate\)'" , "robert.fragassi@alcatel-lucent.com" , "pmohapat@cumulusnetworks.com" Subject: Re: [Idr] IPR on draft-ietf-idr-add-paths-guidelines X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 15:56:16 -0000 --_000_B17A6910EEDD1F45980687268941550F1FF2140AMISOUT7MSGUSRCD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No IPR related to draft-ietf-idr-add-paths-guidelines Thanks, Jim Uttaro From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, August 26, 2016 11:42 AM To: idr@ietf.org; draft-ietf-idr-add-paths-guidelines@ietf.org Cc: 'John Scudder' ; 'Susan Hares' ; 'Key= ur Patel (keyupate)' ; UTTARO, JAMES ; = 'Jeffrey Haas' ; pmohapat@cumulusnetworks.com; robert.fraga= ssi@alcatel-lucent.com; adam.simpson@alcatel-lucent.com; pierre.francois@im= dea.org Subject: IPR on draft-ietf-idr-add-paths-guidelines Jim, Pierre, Pradosh, Robert, Adam, Keyur, and Jeff: Prior to submitting any document for publication of RFC, the shepherd must = check the IPR. Would you please indicate (by responding to this email), if= you know of any IPR related to draft-idr-add-paths-guidelines. I would a= ppreciate if you respond to email so that the IPR declarations are stored i= n the IDR archive. Sue --_000_B17A6910EEDD1F45980687268941550F1FF2140AMISOUT7MSGUSRCD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No IPR related t= o draft-ietf-idr-add-paths-guidelines

 

Thanks,

  &nbs= p;             = Jim Uttaro

 

From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, August 26, 2016 11:42 AM
To: idr@ietf.org; draft-ietf-idr-add-paths-guidelines@ietf.org
Cc: 'John Scudder' <jgs@juniper.net>; 'Susan Hares' <shares= @ndzh.com>; 'Keyur Patel (keyupate)' <keyupate@cisco.com>; UTTARO,= JAMES <ju1738@att.com>; 'Jeffrey Haas' <jhaas@pfrc.org>; pmoha= pat@cumulusnetworks.com; robert.fragassi@alcatel-lucent.com; adam.simpson@a= lcatel-lucent.com; pierre.francois@imdea.org
Subject: IPR on draft-ietf-idr-add-paths-guidelines

 

Jim, Pierre, Pradosh, Robert, Adam, Keyur, and Jeff:=

 

Prior to submitting any document for publication of = RFC, the shepherd must check the IPR.  Would you please indicate (by r= esponding to this email), if you know of any IPR related to draft-idr-add-p= aths-guidelines.   I would appreciate if you respond to email so that the IPR declarations are stored in the IDR ar= chive.

 

Sue

 

--_000_B17A6910EEDD1F45980687268941550F1FF2140AMISOUT7MSGUSRCD_-- From nobody Sat Aug 27 09:03:49 2016 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 2AC7B12D16D; Fri, 26 Aug 2016 10:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vRdUJbBUtIqf; Fri, 26 Aug 2016 10:27:24 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A4212D158; Fri, 26 Aug 2016 10:27:23 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 9FA55CD71E53E; Fri, 26 Aug 2016 17:27:20 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u7QHRMpM007220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Aug 2016 17:27:22 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u7QHRLcN028225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Aug 2016 17:27:21 GMT Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.34]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 26 Aug 2016 13:27:21 -0400 From: "Simpson, Adam 1. (Nokia - CA)" To: "UTTARO, JAMES" , Susan Hares , "draft-ietf-idr-add-paths-guidelines@ietf.org" , "idr@ietf.org" Thread-Topic: IPR on draft-ietf-idr-add-paths-guidelines Thread-Index: AQHR/78ZOM8tiBa44ESTj7H1Mohyag== Date: Fri, 26 Aug 2016 17:27:21 +0000 Message-ID: <63BC7A49E096988F.86DC755C-71F1-4E48-BB5F-CD9E689D154C@mail.outlook.com> References: <09a501d1ffb0$64bed510$2e3c7f30$@ndzh.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_63BC7A49E096988F86DC755C71F14E48BB5FCD9E689D154Cmailout_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 27 Aug 2016 09:03:37 -0700 Cc: "'Keyur Patel \(keyupate\)'" , "robert.fragassi@alcatel-lucent.com" , "pmohapat@cumulusnetworks.com" Subject: Re: [Idr] IPR on draft-ietf-idr-add-paths-guidelines X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 17:27:26 -0000 --_000_63BC7A49E096988F86DC755C71F14E48BB5FCD9E689D154Cmailout_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, Speaking for Nokia/Alcatel-Lucent, we have no IPR related to this draft eit= her. -Adam _____________________________ From: UTTARO, JAMES > Sent: Friday, August 26, 2016 8:56 AM Subject: RE: IPR on draft-ietf-idr-add-paths-guidelines To: >, Susan Hares >, > Cc: >, >, 'J= ohn Scudder' >, 'Keyur Patel (keyup= ate)' >, Simpson, Adam 1. (No= kia - CA) >, 'Jef= frey Haas' >, > No IPR related to draft-ietf-idr-add-paths-guidelines Thanks, Jim Uttaro From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, August 26, 2016 11:42 AM To: idr@ietf.org; draft-ietf-idr-add-paths-guidelines@= ietf.org Cc: 'John Scudder' >; 'Susan Hares'= >; 'Keyur Patel (keyupate)' >; UTTARO, JAMES >; 'Jeffrey Haas' >; pmohapat@cumulusnetworks.com; robe= rt.fragassi@alcatel-lucent.com; = adam.simpson@alcatel-lucent.com; pi= erre.francois@imdea.org Subject: IPR on draft-ietf-idr-add-paths-guidelines Jim, Pierre, Pradosh, Robert, Adam, Keyur, and Jeff: Prior to submitting any document for publication of RFC, the shepherd must = check the IPR. Would you please indicate (by responding to this email), if= you know of any IPR related to draft-idr-add-paths-guidelines. I would a= ppreciate if you respond to email so that the IPR declarations are stored i= n the IDR archive. Sue --_000_63BC7A49E096988F86DC755C71F14E48BB5FCD9E689D154Cmailout_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sue,

Speaking for Nokia/Alcatel-Lucent, we have no IPR related to this draf= t either. 

-Adam

_____________________________
From: UTTARO, JAMES <ju1738@att.com>
Sent: Friday, August 26, 2016 8:56 AM
Subject: RE: IPR on draft-ietf-idr-add-paths-guidelines
To: <draft-ietf-idr-add-paths-guidelines@= ietf.org>, Susan Hares <shares@ndzh.com>, <idr@ietf.org>
Cc: <robert.fragassi@alcatel-lucent.com>, &l= t;pierre.francois@imdea.org>, 'John Scudder' <jgs@juniper.net>, 'Keyur Patel (keyupate)' <= ;keyupate@cisco.com>, Simpson, Adam 1. (Nokia - CA) <adam.1.simpson@nokia.com&= gt;, 'Jeffrey Haas' <jhaas@pfrc.org>, <pmohapat@cumulusnetworks.com>


No IPR related t= o draft-ietf-idr-add-paths-guidelines

 

Thanks,

  &nbs= p;             = Jim Uttaro

 

 

Jim, Pierre, Pradosh, Robert, Adam, Keyur, and Jeff:=

 

Prior to submitting any document for publication of = RFC, the shepherd must check the IPR.  Would you please indicate (by r= esponding to this email), if you know of any IPR related to draft-idr-add-p= aths-guidelines.   I would appreciate if you respond to email so that the IPR declarations are stored in the IDR ar= chive.

 

Sue

 



--_000_63BC7A49E096988F86DC755C71F14E48BB5FCD9E689D154Cmailout_-- From keyurpat@yahoo.com Fri Aug 26 13:02:42 2016 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 D1BAF12D5DE for ; Fri, 26 Aug 2016 13:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 bNiZJ_qrzWYS for ; Fri, 26 Aug 2016 13:02:42 -0700 (PDT) Received: from nm7-vm3.bullet.mail.ne1.yahoo.com (nm7-vm3.bullet.mail.ne1.yahoo.com [98.138.91.137]) (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 E02B312D59E for ; Fri, 26 Aug 2016 13:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472241761; bh=bBE6UanDhgipWL5qS2jAON8va1szFGXKRjaEX3KC+QA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=pAObO6YuanevIBuQx0B67pQHNLL/W/PZVCGBaGSAz/Rjv/ifRebLcgXszLzWMpqu+F9q7sNowsLI87WxFL2Bra8acDHzhn04SW0LXPWdT9+XcO+ji3v8QSrx55ATCq8+X6DGczb/DtVH7Eh9YTAlFvFlvjFh1tWtChwQycUw8IJHYwzkfGwcjjPDfbE1lzczr+UAJwWKVhAl1lc5xZGxdHOnzfFQ5CsvnURAgz4N5x6ctYULk9IEfvXn8s2jAmjjyMqxWlov9UFc3jX6DybaNSRypMSUOfiCWJKVUlMZiXtKqFCShs5La+RV96eJSWCspuwxJ09OKEfT9KLFIBpN7A== Received: from [98.138.101.130] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 26 Aug 2016 20:02:41 -0000 Received: from [98.138.84.47] by tm18.bullet.mail.ne1.yahoo.com with NNFMP; 26 Aug 2016 20:02:41 -0000 Received: from [127.0.0.1] by smtp115.mail.ne1.yahoo.com with NNFMP; 26 Aug 2016 20:02:41 -0000 X-Yahoo-Newman-Id: 188070.19590.bm@smtp115.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jLgR7yIVM1nBdpiqlJBv5Yz9Cc6XtuqwUZ7adV8BE.Teqty KHRHB1pF_y17M30a539J9xeSObr6TsHJbHWSXMWsL3O1tvWtbIEtdYayd522 6I8AwaYLa0MDo2hMd7nz1NSgAbup0H6TvvMXCifiN8KL2ZkAQFUYBQ9vdkmB 8Ew_zzCArSUotaQvhtDVnaFOA3RItpMM6yr9wWH6jBw0RABuTyqxIJy1xkUH vphziWLmXgg1Np.zPzxKnrEpqPJguyR7aIHVbyNeQQbO7gXWAWo5NdpXo6CY 9oADABnsNXH.9nXekJroRRG8zpdxA2lqt3vWXfucYT5g3Csc8Aa3UlVWI0Yk r.XT05skzLqihYU9NunHLtHb0qbQR3Wtrw.WXcjyyEG99pQVr3F4q8veMdqO LWOfMU1NmeJvsnFqrvOQcjR.2rDm6QJnje8BMVEvNwlcDUstuKMfIJjpaoxM yTTXH_rD3F._e1r0T_F2lF17YU3BhxGDZMuQ4v5GtbJtDw.AVUu1dX1ioc1W jPMtef61eSOvTbjggk3wuCYjzx0g5btAtb4RWv2e8g5MHAMhhmUaBb4gE.zv P X-Yahoo-SMTP: dTN7da2swBBmAtevEJmtymBGXU.W Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Keyur X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Fri, 26 Aug 2016 13:02:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <096a01d1ffa8$8e0584d0$aa108e70$@ndzh.com> To: Randy Bush Archived-At: X-Mailman-Approved-At: Sat, 27 Aug 2016 09:03:37 -0700 Cc: idr@ietf.org, dward@cisco.com, Susan Hares Subject: Re: [Idr] IPR statement on draft-ietf-idr-extended-messages-13.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 20:04:54 -0000 +1. Regards, Keyur Sent from my iPhone On Aug 26, 2016, at 12:55 PM, Randy Bush wrote: >> As authors of draft-ietf-idr-bgp-extended-messages-13, do you know of an I= PR >> related to draft-ietf-idr-extended-messages-13.txt. >=20 > no >=20 > randy From nobody Mon Aug 29 22:43:12 2016 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 28A4112D121 for ; Mon, 29 Aug 2016 22:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 fd7Cc72y1SEm for ; Mon, 29 Aug 2016 22:43:08 -0700 (PDT) Received: from nm45-vm4.bullet.mail.ne1.yahoo.com (nm45-vm4.bullet.mail.ne1.yahoo.com [98.138.121.68]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C919712D11A for ; Mon, 29 Aug 2016 22:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472535788; bh=AY2GvS7z6ks8kN1qC2vmIrjqK/yUu02TbhW6ng3jpl8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=EyEWzCnRpayRy6kBwlM++2jIsfLa7FOYXtc+H01lfXY/R4DTaxVZ8kE0TLpzAJ6u5+kYFJW7K7uhN4BgiwRVzJg6cO/HwgtzbLe2EJusOI5aNSswD+QOLlf/qonUL34PL4MTHOvnBeuPaLH5JqWhXoLUg0YEmQR9Mcq3IGryYLPjZ8kBBEQgQo+BldPhbRFGtbNQEq/CdyIHznVqhRDlt9sYGOcM5N20mGjEpvyiDT1isco2YsskE3ncCxTdrYI5qgv7znUPHm7MOdSJdnMDH5YdYjJKs5xY5Oe2qHYdlhG9rYhRhufGh7wBwh7j2fDrkB//hyrUojLE4rtzmmQPlg== Received: from [127.0.0.1] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2016 05:43:08 -0000 Received: from [98.138.100.113] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2016 05:40:18 -0000 Received: from [98.138.87.9] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 30 Aug 2016 05:40:18 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 30 Aug 2016 05:40:18 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 251716.19145.bm@omp1009.mail.ne1.yahoo.com X-YMail-OSG: 5Df.dkYVM1kszeY1PNrWH1ZjgBYzpyjbKcGqWiBwnWyetBqXNEtNH57lkymYdX6 0jThVKOnnJZ0NNzMq_srJ.kiZaJTzxMW2e3Bimek5jZik5k4mMPwqj2koDfERcSseBzYxKq_s6bj 2rvV.EsXC5iPIvhPA39SXmiSZHUVDhNH7ZGFi0y1.bvmcbSD62F0kfGsjd0nbVbAqCVTpeVRdgqt uRiNh._VF.9hGtk2zusmHR6SIY1e1Pjg72gh37zRzGJdAp14itH6f6u8l2A7exS0nO.bH4MAEYAi z9ZVGrb8blKjKKvWGV08aQukVwH7an6JArqLHGFe_5dTUvaIPlUc0tYD_U9WySDevUZlB2HBpllz XDpNnfozWJpzsm.jWaOs9_eURn25Vo.E5cRu61dr3V2Bufjx_6jwYrQ86hMzGmrqnGY2yT.idgjJ WK.Mo5ZI2KEwOvpzzSjd8QNvahr5UlFdZEshofuIhExXtu1cX53siE0pWhpZxf279mV5QCccW9.y ve4aQGVUWt7jO9ILOFsOiDX8HkzvvX5M.gyBFiP43qdqLrn.4TdPy.96mKR5mUEhJJCVUzVHoZyQ kLStBpQyVpfgpzHk- Received: from jws100254.mail.ne1.yahoo.com by sendmailws113.mail.ne1.yahoo.com; Tue, 30 Aug 2016 05:40:17 +0000; 1472535617.553 Date: Tue, 30 Aug 2016 05:40:17 +0000 (UTC) From: Pradosh Mohapatra To: Susan Hares , "idr@ietf.org" , "draft-ietf-idr-add-paths-guidelines@ietf.org" Message-ID: <2043813679.1744015.1472535617209@mail.yahoo.com> In-Reply-To: <09a501d1ffb0$64bed510$2e3c7f30$@ndzh.com> References: <09a501d1ffb0$64bed510$2e3c7f30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "'Keyur Patel \(keyupate\)'" , "robert.fragassi@alcatel-lucent.com" , "pmohapat@cumulusnetworks.com" Subject: Re: [Idr] IPR on draft-ietf-idr-add-paths-guidelines X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Pradosh Mohapatra List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 05:43:10 -0000 > Would you please indicate (by responding to this email), if you know of any IPR > related to draft-idr-add-paths-guidelines. No IPR that I know of. Thanks,- Pradosh On Saturday, August 27, 2016 9:03 AM, Susan Hares wrote: Jim, Pierre, Pradosh, Robert, Adam, Keyur, and Jeff: Prior to submitting any document for publication of RFC, the shepherd must check the IPR. Would you please indicate (by responding to this email), if you know of any IPR related to draft-idr-add-paths-guidelines. I would appreciate if you respond to email so that the IPR declarations are stored in the IDR archive. Sue _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Tue Aug 30 21:28:55 2016 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 38D0D12D0CB; Tue, 30 Aug 2016 21:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no 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 YCX9HYnEyIAD; Tue, 30 Aug 2016 21:28:52 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B600B12B00A; Tue, 30 Aug 2016 21:28:51 -0700 (PDT) Received: from [10.143.109.35] (79.138.131.88.mobile.tre.se [79.138.131.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C303F18015A1; Wed, 31 Aug 2016 06:28:48 +0200 (CEST) From: Loa Andersson Content-Type: multipart/alternative; boundary=Apple-Mail-4E4966C5-3D09-447D-9364-488CE5DB8C71 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: <8A502F2D-E7EC-4497-9BF1-1295E1F21A02@pi.nu> Date: Wed, 31 Aug 2016 12:28:43 +0800 References: To: idr@ietf.org, bess@ietf.org X-Mailer: iPhone Mail (13G35) Archived-At: Subject: [Idr] Fwd: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 04:28:54 -0000 --Apple-Mail-4E4966C5-3D09-447D-9364-488CE5DB8C71 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Working Groups, Please note that the working group adoption poll for draft-rosen-mpls-rfc310= 7bis has been started in the mpls wg. Please send your comments to the mpls w= g mailing list (mpls@ietf.org).=20 /Loa mpls wg co-chair Sent from my iPhone Begin forwarded message: > From: Loa Andersson > Date: 30 augusti 2016 08:10:13 GMT+8 > To: "mpls@ietf.org" > Cc: "draft-rosen-mpls-rfc3107bis.all@ietf.org" , "mpls-chairs@ietf.org" > Subject: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis= >=20 > Working Group, >=20 > This is to start a two week poll on adopting draft-rosen-mpls-rfc3107bis > as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > There are no IPR disclosures against this document. >=20 > All the authors has stated on the on the mpls wg mailing list that they > are not aware of any IPRs that relate to this document. >=20 > The working group adoption poll ends September 14, 2016. >=20 > /Loa >=20 > MPLS wg co-chair. > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-4E4966C5-3D09-447D-9364-488CE5DB8C71 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Working Groups,

Please note that the w= orking group adoption poll for draft-rosen-mpls-rfc3107bis has been started i= n the mpls wg. Please send your comments to the mpls wg mailing list (mpls@ietf.org). 

/Loa
mpls wg co-chair

Sent from my iPhone
Begin forwarded message:

From:= Loa Andersson <loa@pi.nu>
= Date: 30 augusti 2016 08:10:13 GMT+8
To: "mpls@ietf.org" <mpls@ie= tf.org>
Cc: "draft-rosen-mpls-rfc3107bis.all@ietf.org" <draft-rosen-mpls-rfc3107bis.= all@ietf.org>, "mpls-chairs@i= etf.org" <mpls-chairs@ietf.or= g>
Subject: [mpls] Working Group adoption poll on draft-= rosen-mpls-rfc3107bis

Working Group,

This is to star= t a two week poll on adopting draft-rosen-mpls-rfc3107bis
as= an MPLS working group document.

Please sen= d your comments (support/not support) to the mpls working
gr= oup mailing list (mpls@ietf.org). Pleas= e give a technical
motivation for your support/not support, e= specially if you think that
the document should not be adopt= ed as a working group document.

There are n= o IPR disclosures against this document.

Al= l the authors has stated on the on the mpls wg mailing list that they=
are not aware of any IPRs that relate to this document.
=
The working group adoption poll ends September 14, 20= 16.

/Loa

M= PLS wg co-chair.
--


Loa Andersson         &nb= sp;            &= nbsp; email: loa@mail01.huawei= .com
Senior MPLS Expert      &n= bsp;            =        loa@p= i.nu
Huawei Technologies (consultant)    =  phone: +46 739 81 21 64

_____________= __________________________________
mpls mailing list<= br>mpls@ietf.org
= https://www.ietf.org/= mailman/listinfo/mpls
= --Apple-Mail-4E4966C5-3D09-447D-9364-488CE5DB8C71-- From nobody Wed Aug 31 02:25:04 2016 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 1240512D8C9; Wed, 31 Aug 2016 02:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 r6DE0kzLCfFj; Wed, 31 Aug 2016 02:24:57 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 3670A12D8C8; Wed, 31 Aug 2016 02:24:57 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id i5so78191936wmg.0; Wed, 31 Aug 2016 02:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8ppgHyZmnC8zpYi+g0IOdjRUKtDLxTIBzmlxAAq/nL8=; b=j7DadHCRKfheck6gN5Z6eD6x1LmXmvehP3/VouNf8i8RH/ptTjX6rTCIbZD6GdX5Tq z8lXEsPTFm2Vnn19errlKKBmCG9zF1QuHOLHhuG2BhQ07HDG5uNRQGJPHOeJ3+znFUfZ iv4AMu1eBbcc+lkPGGaR8Tm0O1CQVeuFWNrwpW08yhrFUDtPwvX1YK1fcLf+wDR0r+Xk dpHpwi3k28vNOWEqMi76IIrNVcIs5pnZfrJOhs2nmJ3ZHrJesNkT4nrjyCZjMLXz6QYm Fs0n/Ri7/TPaPTX3TGobZ/CaD7gRhUIdoKoihDF+WXfd5gbI+ESsMX6BMTpUMkR61Z2u nPrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8ppgHyZmnC8zpYi+g0IOdjRUKtDLxTIBzmlxAAq/nL8=; b=iFoxdGoiPg5eJ/YK60O1nYEXbkOQU6WC0BEPMwhz7wtp9nSsBRat5kCB9RtI+JtRGw /ElPVG/19JEdvrpIOAJnPSneuCqitpznbgVnEbO0GACxi/mNcbZfXxGr9/fvTUpOoWFk 42ZnpxKdNAEsU3tk+9ORjJpDyQzLKxt304nsnF5WbNhrsVBYC2KCS+p8A+lz95uCF5fa D7uW8XorEPe3dDwuyZt1xSGA5+IQuUgg4+Gjav+Z7J4yXxgPwBwRbZ74l2gERmNzKn12 N+4Zm4pYyQrhZPRum2+caSHRL9J7sX9SJbdn6YU742bAlev5TJRr7D3C3A+lFoCfr5b8 dNTw== X-Gm-Message-State: AE9vXwNxo3RG9dwbWCGk9NOFnjhZX2hH4DkC1bfV7FWIYAkYo2iz3L7QNWcnXHc8Y7rDhicM4+HMsg3G5XnWEQ== X-Received: by 10.194.89.228 with SMTP id br4mr7971214wjb.187.1472635495622; Wed, 31 Aug 2016 02:24:55 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.194.60.51 with HTTP; Wed, 31 Aug 2016 02:24:54 -0700 (PDT) In-Reply-To: <8A502F2D-E7EC-4497-9BF1-1295E1F21A02@pi.nu> References: <8A502F2D-E7EC-4497-9BF1-1295E1F21A02@pi.nu> From: Robert Raszuk Date: Wed, 31 Aug 2016 11:24:54 +0200 X-Google-Sender-Auth: E4g6pGvmRxeCp6mHJjq94JPtYwE Message-ID: To: Eric Rosen Content-Type: multipart/alternative; boundary=047d7bf10ada99bf81053b5aab27 Archived-At: Cc: idr wg , "mpls@ietf.org" , "bess@ietf.org" Subject: Re: [Idr] Fwd: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 09:24:59 -0000 --047d7bf10ada99bf81053b5aab27 Content-Type: text/plain; charset=UTF-8 Hi Eric, While adoption call is sort of encouragement for further input before I respond to Loa's mail I would like to get one additional answer from 3107bis authors and WGs members. Those who spend years in mpls deployment know quite well that the biggest issue with today's 3107 deployment is lack of the clear definition of its interaction with SAFI-1. While one would hope that 3107bis with new capability will clean this mess section 5 of your document rather sweeps it all under the carpet stating that it is just local policy. IMO it is not a matter of local policy nor it is implementation detail. Local policy can be to choose which RIB (or sequence of RIBs) should be used for resolution of specific SAFIs and not how to mix SAFI-1 with SAFI-4. It's not a local matter at all to have deployment resulting in inconsistent IBGP best paths across given domain. To me cleanest is to separate those two SAFIs completely from each other by the spec both in BGP (done) as well as local RIB and FIB/LFIB. Likewise I do not quite agree that SAFI-4 should be "convertible" to SAFI-1. And we all realize that opposite direction is rather hard. Another perhaps minor clarification would be to get an explicit confirmation that SAFI-4 can be recursive over SAFI-4 or for that matter SAFI-1 (MPLS in GRE or SR in IP). Thx, R. --047d7bf10ada99bf81053b5aab27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eric,

While adoption call is sort of encouragement for fur= ther input before I respond to Loa's mail I would like to get one addit= ional answer from 3107bis authors and WGs members.=C2=A0

Those who spend years in mpls deployment= know quite well that the biggest issue with today's 3107 deployment is= lack of the clear definition of its interaction with SAFI-1. While one wou= ld hope that 3107bis with new capability will clean this mess section 5 of = your document rather sweeps it all under the carpet stating that it is just= local policy. IMO it is not a matter of local policy nor it is implementat= ion detail.=C2=A0

Loca= l policy can be to choose which RIB (or sequence of RIBs) should be used fo= r resolution of specific SAFIs and not how to mix SAFI-1 with SAFI-4. It= 9;s not a local matter at all to have deployment resulting in inconsistent = IBGP best paths across given domain.=C2=A0

To me cleanest is to separate those two SAFIs complete= ly from each other by the spec both in BGP (done) as well as local RIB and = FIB/LFIB.=C2=A0

Likewi= se I do not quite agree that SAFI-4 should be "convertible" to SA= FI-1. And we all realize that opposite direction is rather hard.=C2=A0

Another perhaps minor clar= ification would be to get an explicit confirmation that SAFI-4 can be recur= sive over SAFI-4 or for that matter SAFI-1 (MPLS in GRE or SR in IP).=C2=A0=

Thx,
R.

--047d7bf10ada99bf81053b5aab27-- From nobody Wed Aug 31 06:48:16 2016 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D20512D568; Wed, 31 Aug 2016 06:48:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147265129536.13312.907651168846286975.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 06:48:15 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 13:48:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing of the IETF. Title : Flowspec Indirection-id Redirect Authors : Gunter Van de Velde Keyur Patel Zhenbin Li Filename : draft-ietf-idr-flowspec-path-redirect-00.txt Pages : 14 Date : 2016-08-30 Abstract: Flowspec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for policy-based forwarding but this mechanism is not always sufficient, particularly if the redirected traffic needs to be steered into an engineered path or into a service plane. This document defines a new extended community known as redirect-to- indirection-id (32-bit) flowspec action to provide advanced redirection capabilities on flowspec clients. When activated, the flowspec extended community is used by a flowspec client to find the correct next-hop entry within a localised indirection-id mapping table. The functionality present in this draft allows a network controller to decouple flowspec functionality from the creation and maintainance of the network's service plane itself including the setup of tunnels and other service constructs that could be managed by other network devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 31 07:37:34 2016 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 5BEA912DB8D; Wed, 31 Aug 2016 07:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 kO5HmydG3n7n; Wed, 31 Aug 2016 07:37:24 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7FC12DCAB; Wed, 31 Aug 2016 07:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11345; q=dns/txt; s=iport; t=1472652905; x=1473862505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CvM5Q8KFKzcjkuzN9CMh0R/5Ca4qBk9jNLU2/cZ8cMA=; b=CgXq+qzV+2DFz5aLCvffLUZKYZJVD1kvPvmY8rqEEcmBi7s0nWjCDPxe b7Ap5N/VI7FosiybfbYgzz07KvJLWHM9jxVT/sd71kYrP2kVcKAQuGwOm dbIOFzA3zBnKF0aadac9T/H8A5y8KoJLow3oNUE9tEH94Vp6arS+W3j3b c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AgAY5sZX/5xdJa1dgxozAQEBAQEeg?= =?us-ascii?q?VMHg0CvUoUNggGGHQIcgS04FAECAQEBAQEBAV4nhGEBAQUjVhACAQgRAwECKAM?= =?us-ascii?q?CAgIwFAkIAgQBDQUbiCuuZI8jAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIl5gQOEI?= =?us-ascii?q?wEBO4JigloFmVABjy+PV4xIg3gBHjaCeoE1cIRNgSB/AQEB?= X-IronPort-AV: E=Sophos;i="5.30,262,1470700800"; d="scan'208,217";a="147426382" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2016 14:15:04 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u7VEF2kl003951 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 14:15:04 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 10:15:02 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 10:15:02 -0400 From: "Acee Lindem (acee)" To: Robert Raszuk , Eric Rosen Thread-Topic: [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis Thread-Index: AQHSA2mTmZjCk1nk8UG09DsTehNMO6BjHUgA Date: Wed, 31 Aug 2016 14:15:01 +0000 Message-ID: References: <8A502F2D-E7EC-4497-9BF1-1295E1F21A02@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: multipart/alternative; boundary="_000_D3EC5D037C805aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg , "bess@ietf.org" , "mpls@ietf.org" Subject: Re: [Idr] [mpls] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 14:37:28 -0000 --_000_D3EC5D037C805aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpDdXJyZW50bHksIGV2ZXJ5dGhpbmcgaW4gZHJhZnQtcm9zZW4tbXBscy1y ZmMzMTA3YmlzIGlzIHByZXR0eSBtdWNoIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBvdXIgbW9y ZSB0aGFuIGEgZGVjYWRlIG9sZCBSRkMgMzEwNyBpbXBsZW1lbnRhdGlvbnMgYW5kIGRlcGxveW1l bnRzLiBXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIGlzIG5vdCBhbmQgaGFzIGltcGxpY2F0aW9ucyBp biBib3RoIHRoZSBjb250cm9sIGFuZCBmb3J3YXJkaW5nIHBsYW5lcy4gSWYgeW91IHJlYWxseSBi ZWxpZXZlIHRoYXQgdGhpcyBpcyDigJx0aGUgYmlnZ2VzdCBpc3N1ZSIsIEnigJlkIHN1Z2dlc3Qg eW91IGFydGljdWxhdGUgaXQgaW4gYSBzZXBhcmF0ZSBkcmFmdCB3aXRoIGNvbmNyZXRlIHVzZSBj YXNlcyBmb3IgaGF2aW5nIHNlcGFyYXRlIElQIGFuZCBNUExTIHRvcG9sb2dpZXMgZm9yIHRoZSBz YW1lIHNldCBvZiBwcmVmaXhlcy4gVGhlbiB0aGUgV0dzIGNhbiBldmFsdWF0ZSB0aGUgcmVxdWly ZW1lbnQgYW5kIHByb3Bvc2VkIHNvbHV0aW9uIGluZGVwZW5kZW50IG9mIFJGQyAzMTA3IEJJUy4N Cg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBSb2JlcnQgUmFzenVrIDxy b2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KRGF0ZTogV2VkbmVz ZGF5LCBBdWd1c3QgMzEsIDIwMTYgYXQgNToyNCBBTQ0KVG86IEVyaWMgQyBSb3NlbiA8ZXJvc2Vu QGp1bmlwZXIubmV0PG1haWx0bzplcm9zZW5AanVuaXBlci5uZXQ+Pg0KQ2M6IElEUiBMaXN0IDxp ZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+LCAibXBsc0BpZXRmLm9yZzxtYWlsdG86 bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4sICJi ZXNzQGlldGYub3JnPG1haWx0bzpiZXNzQGlldGYub3JnPiIgPGJlc3NAaWV0Zi5vcmc8bWFpbHRv OmJlc3NAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFttcGxzXSBbSWRyXSBGd2Q6IFdvcmtpbmcg R3JvdXAgYWRvcHRpb24gcG9sbCBvbiBkcmFmdC1yb3Nlbi1tcGxzLXJmYzMxMDdiaXMNCg0KSGkg RXJpYywNCg0KV2hpbGUgYWRvcHRpb24gY2FsbCBpcyBzb3J0IG9mIGVuY291cmFnZW1lbnQgZm9y IGZ1cnRoZXIgaW5wdXQgYmVmb3JlIEkgcmVzcG9uZCB0byBMb2EncyBtYWlsIEkgd291bGQgbGlr ZSB0byBnZXQgb25lIGFkZGl0aW9uYWwgYW5zd2VyIGZyb20gMzEwN2JpcyBhdXRob3JzIGFuZCBX R3MgbWVtYmVycy4NCg0KVGhvc2Ugd2hvIHNwZW5kIHllYXJzIGluIG1wbHMgZGVwbG95bWVudCBr bm93IHF1aXRlIHdlbGwgdGhhdCB0aGUgYmlnZ2VzdCBpc3N1ZSB3aXRoIHRvZGF5J3MgMzEwNyBk ZXBsb3ltZW50IGlzIGxhY2sgb2YgdGhlIGNsZWFyIGRlZmluaXRpb24gb2YgaXRzIGludGVyYWN0 aW9uIHdpdGggU0FGSS0xLiBXaGlsZSBvbmUgd291bGQgaG9wZSB0aGF0IDMxMDdiaXMgd2l0aCBu ZXcgY2FwYWJpbGl0eSB3aWxsIGNsZWFuIHRoaXMgbWVzcyBzZWN0aW9uIDUgb2YgeW91ciBkb2N1 bWVudCByYXRoZXIgc3dlZXBzIGl0IGFsbCB1bmRlciB0aGUgY2FycGV0IHN0YXRpbmcgdGhhdCBp dCBpcyBqdXN0IGxvY2FsIHBvbGljeS4gSU1PIGl0IGlzIG5vdCBhIG1hdHRlciBvZiBsb2NhbCBw b2xpY3kgbm9yIGl0IGlzIGltcGxlbWVudGF0aW9uIGRldGFpbC4NCg0KTG9jYWwgcG9saWN5IGNh biBiZSB0byBjaG9vc2Ugd2hpY2ggUklCIChvciBzZXF1ZW5jZSBvZiBSSUJzKSBzaG91bGQgYmUg dXNlZCBmb3IgcmVzb2x1dGlvbiBvZiBzcGVjaWZpYyBTQUZJcyBhbmQgbm90IGhvdyB0byBtaXgg U0FGSS0xIHdpdGggU0FGSS00LiBJdCdzIG5vdCBhIGxvY2FsIG1hdHRlciBhdCBhbGwgdG8gaGF2 ZSBkZXBsb3ltZW50IHJlc3VsdGluZyBpbiBpbmNvbnNpc3RlbnQgSUJHUCBiZXN0IHBhdGhzIGFj cm9zcyBnaXZlbiBkb21haW4uDQoNClRvIG1lIGNsZWFuZXN0IGlzIHRvIHNlcGFyYXRlIHRob3Nl IHR3byBTQUZJcyBjb21wbGV0ZWx5IGZyb20gZWFjaCBvdGhlciBieSB0aGUgc3BlYyBib3RoIGlu IEJHUCAoZG9uZSkgYXMgd2VsbCBhcyBsb2NhbCBSSUIgYW5kIEZJQi9MRklCLg0KDQpMaWtld2lz ZSBJIGRvIG5vdCBxdWl0ZSBhZ3JlZSB0aGF0IFNBRkktNCBzaG91bGQgYmUgImNvbnZlcnRpYmxl IiB0byBTQUZJLTEuIEFuZCB3ZSBhbGwgcmVhbGl6ZSB0aGF0IG9wcG9zaXRlIGRpcmVjdGlvbiBp cyByYXRoZXIgaGFyZC4NCg0KQW5vdGhlciBwZXJoYXBzIG1pbm9yIGNsYXJpZmljYXRpb24gd291 bGQgYmUgdG8gZ2V0IGFuIGV4cGxpY2l0IGNvbmZpcm1hdGlvbiB0aGF0IFNBRkktNCBjYW4gYmUg cmVjdXJzaXZlIG92ZXIgU0FGSS00IG9yIGZvciB0aGF0IG1hdHRlciBTQUZJLTEgKE1QTFMgaW4g R1JFIG9yIFNSIGluIElQKS4NCg0KVGh4LA0KUi4NCg0K --_000_D3EC5D037C805aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2JlcnQs Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DdXJyZW50bHksIGV2ZXJ5dGhp bmcgaW4gZHJhZnQtcm9zZW4tbXBscy1yZmMzMTA3YmlzIGlzIHByZXR0eSBtdWNoIGJhY2t3YXJk IGNvbXBhdGlibGUgd2l0aCBvdXIgbW9yZSB0aGFuIGEgZGVjYWRlIG9sZCBSRkMgMzEwNyBpbXBs ZW1lbnRhdGlvbnMgYW5kIGRlcGxveW1lbnRzLiBXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIGlzIG5v dCBhbmQgaGFzIGltcGxpY2F0aW9ucyBpbiBib3RoIHRoZSBjb250cm9sIGFuZCBmb3J3YXJkaW5n IHBsYW5lcy4NCiBJZiB5b3UgcmVhbGx5IGJlbGlldmUgdGhhdCB0aGlzIGlzIOKAnHRoZSBiaWdn ZXN0IGlzc3VlJnF1b3Q7LCBJ4oCZZCBzdWdnZXN0IHlvdSBhcnRpY3VsYXRlIGl0IGluIGEgc2Vw YXJhdGUgZHJhZnQgd2l0aCBjb25jcmV0ZSB1c2UgY2FzZXMgZm9yIGhhdmluZyBzZXBhcmF0ZSBJ UCBhbmQgTVBMUyB0b3BvbG9naWVzIGZvciB0aGUgc2FtZSBzZXQgb2YgcHJlZml4ZXMuIFRoZW4g dGhlIFdHcyBjYW4gZXZhbHVhdGUgdGhlIHJlcXVpcmVtZW50IGFuZCBwcm9wb3NlZA0KIHNvbHV0 aW9uIGluZGVwZW5kZW50IG9mIFJGQyAzMTA3IEJJUy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZTwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpi bGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6 IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVt IG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkZyb206IDwvc3Bhbj5tcGxzICZsdDs8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnIj5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgUm9iZXJ0IFJh c3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVr Lm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwv c3Bhbj5XZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiBhdCA1OjI0IEFNPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+RXJpYyBDIFJvc2VuICZsdDs8YSBocmVm PSJtYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0Ij5lcm9zZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPklEUiBMaXN0ICZs dDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7 LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXNzQGlldGYub3JnIj5iZXNzQGlldGYub3JnPC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFu PlJlOiBbbXBsc10gW0lkcl0gRndkOiBXb3JraW5nIEdyb3VwIGFkb3B0aW9uIHBvbGwgb24gZHJh ZnQtcm9zZW4tbXBscy1yZmMzMTA3YmlzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQpIaSBFcmljLDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVm YXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQt c2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0 eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21h bGwiPg0KV2hpbGUgYWRvcHRpb24gY2FsbCBpcyBzb3J0IG9mIGVuY291cmFnZW1lbnQgZm9yIGZ1 cnRoZXIgaW5wdXQgYmVmb3JlIEkgcmVzcG9uZCB0byBMb2EncyBtYWlsIEkgd291bGQgbGlrZSB0 byBnZXQgb25lIGFkZGl0aW9uYWwgYW5zd2VyIGZyb20gMzEwN2JpcyBhdXRob3JzIGFuZCBXR3Mg bWVtYmVycy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJm b250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0K PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1p bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClRob3NlIHdo byBzcGVuZCB5ZWFycyBpbiBtcGxzIGRlcGxveW1lbnQga25vdyBxdWl0ZSB3ZWxsIHRoYXQgdGhl IGJpZ2dlc3QgaXNzdWUgd2l0aCB0b2RheSdzIDMxMDcgZGVwbG95bWVudCBpcyBsYWNrIG9mIHRo ZSBjbGVhciBkZWZpbml0aW9uIG9mIGl0cyBpbnRlcmFjdGlvbiB3aXRoIFNBRkktMS4gV2hpbGUg b25lIHdvdWxkIGhvcGUgdGhhdCAzMTA3YmlzIHdpdGggbmV3IGNhcGFiaWxpdHkgd2lsbCBjbGVh biB0aGlzIG1lc3Mgc2VjdGlvbiA1DQogb2YgeW91ciBkb2N1bWVudCByYXRoZXIgc3dlZXBzIGl0 IGFsbCB1bmRlciB0aGUgY2FycGV0IHN0YXRpbmcgdGhhdCBpdCBpcyBqdXN0IGxvY2FsIHBvbGlj eS4gSU1PIGl0IGlzIG5vdCBhIG1hdHRlciBvZiBsb2NhbCBwb2xpY3kgbm9yIGl0IGlzIGltcGxl bWVudGF0aW9uIGRldGFpbC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6 c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0i Zm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4N CkxvY2FsIHBvbGljeSBjYW4gYmUgdG8gY2hvb3NlIHdoaWNoIFJJQiAob3Igc2VxdWVuY2Ugb2Yg UklCcykgc2hvdWxkIGJlIHVzZWQgZm9yIHJlc29sdXRpb24gb2Ygc3BlY2lmaWMgU0FGSXMgYW5k IG5vdCBob3cgdG8gbWl4IFNBRkktMSB3aXRoIFNBRkktNC4gSXQncyBub3QgYSBsb2NhbCBtYXR0 ZXIgYXQgYWxsIHRvIGhhdmUgZGVwbG95bWVudCByZXN1bHRpbmcgaW4gaW5jb25zaXN0ZW50IElC R1AgYmVzdCBwYXRocyBhY3Jvc3MgZ2l2ZW4gZG9tYWluLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtm b250LXNpemU6c21hbGwiPg0KVG8gbWUgY2xlYW5lc3QgaXMgdG8gc2VwYXJhdGUgdGhvc2UgdHdv IFNBRklzIGNvbXBsZXRlbHkgZnJvbSBlYWNoIG90aGVyIGJ5IHRoZSBzcGVjIGJvdGggaW4gQkdQ IChkb25lKSBhcyB3ZWxsIGFzIGxvY2FsIFJJQiBhbmQgRklCL0xGSUIuJm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpMaWtld2lzZSBJIGRvIG5vdCBxdWl0ZSBhZ3JlZSB0 aGF0IFNBRkktNCBzaG91bGQgYmUgJnF1b3Q7Y29udmVydGlibGUmcXVvdDsgdG8gU0FGSS0xLiBB bmQgd2UgYWxsIHJlYWxpemUgdGhhdCBvcHBvc2l0ZSBkaXJlY3Rpb24gaXMgcmF0aGVyIGhhcmQu Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1p bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpBbm90aGVyIHBlcmhhcHMg bWlub3IgY2xhcmlmaWNhdGlvbiB3b3VsZCBiZSB0byBnZXQgYW4gZXhwbGljaXQgY29uZmlybWF0 aW9uIHRoYXQgU0FGSS00IGNhbiBiZSByZWN1cnNpdmUgb3ZlciBTQUZJLTQgb3IgZm9yIHRoYXQg bWF0dGVyIFNBRkktMSAoTVBMUyBpbiBHUkUgb3IgU1IgaW4gSVApLiZuYnNwOzwvZGl2Pg0KPGRp diBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGlj YSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1z ZXJpZjtmb250LXNpemU6c21hbGwiPg0KVGh4LDxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQpSLjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpz bWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D3EC5D037C805aceeciscocom_-- From nobody Wed Aug 31 08:10:44 2016 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 0952F12D62A; Wed, 31 Aug 2016 08:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 p8hIxlgjk1R2; Wed, 31 Aug 2016 08:10:32 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 1FCB012DCB7; Wed, 31 Aug 2016 07:40:25 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id 1so44958813wmz.1; Wed, 31 Aug 2016 07:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DtQ5YJ9lnCmuiCEeJPrq9bckvr1B0A+vJi0Or0e5PsU=; b=0HtzafiuUBJKP6aFGESp9BdNs+LqK03BhUFzZy+tv3/GGo1H31IDVRNpjVGrpkNQHe qF4CmEygfmGjJpXanVha6hP28D6zVAVd3uLbl5VS1PFYKgD8YIsNMhqUB3GsfmtDHSyC A/F7qgF/oELlsCzp04JuoDUVGpqWDCwoFzYRpoBcaef9mTVo6LYmAJkHg+16Ua2SgE9r gB/AJ/4vJN9gHIBBrZupSWSnrh64x0kO2rDFsu7SEEe1AwwqvYVINsNVhDWm55Q0Co1a NeXs2sl9fN/7/n3xGSmtJ8Xz+VanwgYQl3r17RdwtcpKZ8bNwVjfCfGQohg3MKifnH7G +EGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DtQ5YJ9lnCmuiCEeJPrq9bckvr1B0A+vJi0Or0e5PsU=; b=f3MPG1WJui/a12qciH9MQfrv/npuDDD6FQB+XQjNOo2sE9gZWHXzfwGP7IQDt6az8Z unbo/yZedcwpH53QUbfgQHcxPR45k5Jc/Iq9PJDThQ8kTYEiGfHxzegdYqsyS9Y2zDm2 FgMWJRCbC1XnAGCtF8dmFibckf7GksSdGDq640acKaa2y+SjM/QhjDLBMLzv7qeZ/DI1 OZe4lc5RKWJitPVZZPGmYvxQj2DWI4caZOVTLfDdgpseUhtH7pW58inLXT+pTgNNNirB FA5Mi+Gl4D+pM8W8HQr5mps2QwnudEgduvYR9MxqI634sqnBIxGZqXiB4kMSaSjYAfm5 lstA== X-Gm-Message-State: AE9vXwOTP5gX7qF3l3HadcWuXhpfzpel/RUzBkbNIu4n3B4BcJTQBYuGiNEGiJDuTuGo5gxQF0DwFazD1D9dVA== X-Received: by 10.194.89.228 with SMTP id br4mr9322896wjb.187.1472654424286; Wed, 31 Aug 2016 07:40:24 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.194.60.51 with HTTP; Wed, 31 Aug 2016 07:40:23 -0700 (PDT) In-Reply-To: References: <8A502F2D-E7EC-4497-9BF1-1295E1F21A02@pi.nu> From: Robert Raszuk Date: Wed, 31 Aug 2016 16:40:23 +0200 X-Google-Sender-Auth: sz8SfHH0JA60m8ByIZNA0wGBzlw Message-ID: To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=047d7bf10adad64b5e053b5f1321 Archived-At: Cc: idr wg , "bess@ietf.org" , "mpls@ietf.org" Subject: Re: [Idr] [mpls] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:10:40 -0000 --047d7bf10adad64b5e053b5f1321 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Acee, There is no issue for compatibility as new proposal has its new BGP capability hence there is no issue with deploying it gradually. Yes it requires new RIB work for those implementations which today use single RIB for both SAFI 1 and SAFI 4. FIB and LFIB are already separate. Each SAFI in BGP also normally has it's own separate tables. So if anything it requires a bit of cleanup work. Main motivation here would be to help new vendors to make the unified choice in how they will implement 3107bis so long term we get some consistent way SAFI 4 is delivered. And if now at the "bis" rfc is not a good time then what you are really advocating is to stay for years to come with such undefined randomness across implementations. Other then consistency I also see folks trying to use labeled BGP as controller to network device protocol to install labels. For that use case alone complete separation from SAFI 1 is very helpful. Thx, R. On Wed, Aug 31, 2016 at 4:15 PM, Acee Lindem (acee) wrote: > Hi Robert, > > Currently, everything in draft-rosen-mpls-rfc3107bis is pretty much > backward compatible with our more than a decade old RFC 3107 > implementations and deployments. What you are proposing is not and has > implications in both the control and forwarding planes. If you really > believe that this is =E2=80=9Cthe biggest issue", I=E2=80=99d suggest you= articulate it in > a separate draft with concrete use cases for having separate IP and MPLS > topologies for the same set of prefixes. Then the WGs can evaluate the > requirement and proposed solution independent of RFC 3107 BIS. > > Thanks, > Acee > > From: mpls on behalf of Robert Raszuk < > robert@raszuk.net> > Date: Wednesday, August 31, 2016 at 5:24 AM > To: Eric C Rosen > Cc: IDR List , "mpls@ietf.org" , " > bess@ietf.org" > Subject: Re: [mpls] [Idr] Fwd: Working Group adoption poll on > draft-rosen-mpls-rfc3107bis > > Hi Eric, > > While adoption call is sort of encouragement for further input before I > respond to Loa's mail I would like to get one additional answer from > 3107bis authors and WGs members. > > Those who spend years in mpls deployment know quite well that the biggest > issue with today's 3107 deployment is lack of the clear definition of its > interaction with SAFI-1. While one would hope that 3107bis with new > capability will clean this mess section 5 of your document rather sweeps = it > all under the carpet stating that it is just local policy. IMO it is not = a > matter of local policy nor it is implementation detail. > > Local policy can be to choose which RIB (or sequence of RIBs) should be > used for resolution of specific SAFIs and not how to mix SAFI-1 with > SAFI-4. It's not a local matter at all to have deployment resulting in > inconsistent IBGP best paths across given domain. > > To me cleanest is to separate those two SAFIs completely from each other > by the spec both in BGP (done) as well as local RIB and FIB/LFIB. > > Likewise I do not quite agree that SAFI-4 should be "convertible" to > SAFI-1. And we all realize that opposite direction is rather hard. > > Another perhaps minor clarification would be to get an explicit > confirmation that SAFI-4 can be recursive over SAFI-4 or for that matter > SAFI-1 (MPLS in GRE or SR in IP). > > Thx, > R. > > --047d7bf10adad64b5e053b5f1321 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Acee,

There is no issue for compatibility as new proposal = has its new BGP capability hence there is no issue with deploying it gradua= lly.=C2=A0

Yes it requ= ires new RIB work for those implementations which today use single RIB for = both SAFI 1 and SAFI 4. FIB and LFIB are already separate. Each SAFI in BGP= also normally has it's own separate tables. So if anything it requires= a bit of cleanup work.=C2=A0

Main motivation here would be to help new vendors to make the unif= ied choice in how they will implement 3107bis so long term we get some cons= istent way SAFI 4 is delivered. And if now at the "bis" rfc is no= t a good time then what you are really advocating is to stay for years to c= ome with such undefined randomness across implementations.=C2=A0

Other then consistency I also se= e folks trying to use labeled BGP as controller to network device protocol = to install labels. For that use case alone complete separation from SAFI 1 = is very helpful.=C2=A0

Thx,
R.



On Wed, Aug 31, 2016 at 4:15 PM, Acee Lindem (acee) <acee@cisco.com= > wrote:
Hi Robert,=C2=A0

Currently, everything in draft-rosen-mpls-rfc3107bis is pretty much ba= ckward compatible with our more than a decade old RFC 3107 implementations = and deployments. What you are proposing is not and has implications in both= the control and forwarding planes. If you really believe that this is =E2=80=9Cthe biggest issue", I=E2= =80=99d suggest you articulate it in a separate draft with concrete use cas= es for having separate IP and MPLS topologies for the same set of prefixes.= Then the WGs can evaluate the requirement and proposed solution independent of RFC 3107 BIS.=C2=A0

Thanks,
Acee

From: mpls <mpls-bounces@ietf.org> on beh= alf of Robert Raszuk <robert@raszuk.net>
Date: Wednesday, August 31, 2016 at= 5:24 AM
To: Eric C Rosen <erosen@juniper.net>
Cc: IDR List <idr@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [mpls] [Idr] Fwd: Work= ing Group adoption poll on draft-rosen-mpls-rfc3107bis

Hi Eric,

While adoption call is sort of encouragement for further input before I res= pond to Loa's mail I would like to get one additional answer from 3107b= is authors and WGs members.=C2=A0

Those who spend years in mpls deployment know quite well that the biggest i= ssue with today's 3107 deployment is lack of the clear definition of it= s interaction with SAFI-1. While one would hope that 3107bis with new capab= ility will clean this mess section 5 of your document rather sweeps it all under the carpet stating that it is = just local policy. IMO it is not a matter of local policy nor it is impleme= ntation detail.=C2=A0

Local policy can be to choose which RIB (or sequence of RIBs) should be use= d for resolution of specific SAFIs and not how to mix SAFI-1 with SAFI-4. I= t's not a local matter at all to have deployment resulting in inconsist= ent IBGP best paths across given domain.=C2=A0

To me cleanest is to separate those two SAFIs completely from each other by= the spec both in BGP (done) as well as local RIB and FIB/LFIB.=C2=A0

Likewise I do not quite agree that SAFI-4 should be "convertible"= to SAFI-1. And we all realize that opposite direction is rather hard.=C2= =A0

Another perhaps minor clarification would be to get an explicit confirmatio= n that SAFI-4 can be recursive over SAFI-4 or for that matter SAFI-1 (MPLS = in GRE or SR in IP).=C2=A0

Thx,
R.

--047d7bf10adad64b5e053b5f1321-- From nobody Wed Aug 31 16:41:10 2016 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 BD70912D74E; Wed, 31 Aug 2016 16:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.068 X-Spam-Level: X-Spam-Status: No, score=-15.068 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 PXiz7e0pmsyH; Wed, 31 Aug 2016 16:40:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E5112D743; Wed, 31 Aug 2016 16:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24281; q=dns/txt; s=iport; t=1472686859; x=1473896459; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bZxW4XbQzLbooaITQpYLX3X/ouxSrCOnHIjCoYrbqF8=; b=NsNv+dVIhKi/kZfu9RyCFI6l4C7B4zDm6e+40FcBtzhb58Jtnintf0re llqXoVRncMHNRn3uLBJhhGH3d3VW3B2KVgUOtbcLCv3B58NHKJYLs5fGj ZrwlyciNBoXuVnYj+uNDnFobFbGA+Aakui1iWoGUmUBM6I/8BsIAFBRcR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAgDtacdX/4cNJK1dgx0zAQEBAQEeg?= =?us-ascii?q?VMHq2yHKIUNggGGHAIcgS04FAECAQEBAQEBAV4nhGEBAQUjVhACAQgRAwECKAM?= =?us-ascii?q?CAgIfERQJCAIEDgUbiBMDF659iTYNgy8BAQEBAQEBAwEBAQEBAQEBAR6JeYEDg?= =?us-ascii?q?kOBYAEBO4JigloFmRw0AYxdglOPV4g/hAmDeAEeNoJ8gTVwhE2BIH8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,264,1470700800"; d="scan'208,217";a="143997263" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2016 23:40:58 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7VNevkK027951 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 23:40:57 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 19:40:57 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 19:40:56 -0400 From: "Acee Lindem (acee)" To: Robert Raszuk Thread-Topic: [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis Thread-Index: AQHSA2mTmZjCk1nk8UG09DsTehNMO6BjHUgAgABKKICAAFP3AA== Date: Wed, 31 Aug 2016 23:40:56 +0000 Message-ID: References: <8A502F2D-E7EC-4497-9BF1-1295E1F21A02@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: multipart/alternative; boundary="_000_D3ECD8487C9C7aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg , "bess@ietf.org" , "mpls@ietf.org" Subject: Re: [Idr] [mpls] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 23:41:02 -0000 --_000_D3ECD8487C9C7aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpGcm9tOiA8cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21h aWwuY29tPj4gb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+DQpEYXRlOiBXZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAx NiBhdCAxMDo0MCBBTQ0KVG86IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNl ZUBjaXNjby5jb20+Pg0KQ2M6IEVyaWMgQyBSb3NlbiA8ZXJvc2VuQGp1bmlwZXIubmV0PG1haWx0 bzplcm9zZW5AanVuaXBlci5uZXQ+PiwgSURSIExpc3QgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRy QGlldGYub3JnPj4sICJtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiIgPG1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PiwgImJlc3NAaWV0Zi5vcmc8bWFpbHRvOmJl c3NAaWV0Zi5vcmc+IiA8YmVzc0BpZXRmLm9yZzxtYWlsdG86YmVzc0BpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW21wbHNdIFtJZHJdIEZ3ZDogV29ya2luZyBHcm91cCBhZG9wdGlvbiBwb2xsIG9u IGRyYWZ0LXJvc2VuLW1wbHMtcmZjMzEwN2Jpcw0KDQpIaSBBY2VlLA0KDQpUaGVyZSBpcyBubyBp c3N1ZSBmb3IgY29tcGF0aWJpbGl0eSBhcyBuZXcgcHJvcG9zYWwgaGFzIGl0cyBuZXcgQkdQIGNh cGFiaWxpdHkgaGVuY2UgdGhlcmUgaXMgbm8gaXNzdWUgd2l0aCBkZXBsb3lpbmcgaXQgZ3JhZHVh bGx5Lg0KDQpUaGUgY3VycmVudCBjYXBhYmlsaXR5IGlzIHNwZWNpZmljIHRvIHN1cHBvcnQgb2Yg bXVsdGlwbGUgbGFiZWxzIC0gbm90IHlvdXIgcGFyb2NoaWFsIHZpZXcgb24gdGhlIGludGVyYWN0 aW9uIGJldHdlZW4gU0FGSXMuIEFyZSB5b3Ugc3VnZ2VzdGluZyBhIHNlY29uZCBjYXBhYmlsaXR5 PyBBbGwgdGhlIG1vcmUgcmVhc29uIGZvciBhIHNlcGFyYXRlIGRyYWZ0Lg0KDQoNClllcyBpdCBy ZXF1aXJlcyBuZXcgUklCIHdvcmsgZm9yIHRob3NlIGltcGxlbWVudGF0aW9ucyB3aGljaCB0b2Rh eSB1c2Ugc2luZ2xlIFJJQiBmb3IgYm90aCBTQUZJIDEgYW5kIFNBRkkgNC4gRklCIGFuZCBMRklC IGFyZSBhbHJlYWR5IHNlcGFyYXRlLiBFYWNoIFNBRkkgaW4gQkdQIGFsc28gbm9ybWFsbHkgaGFz IGl0J3Mgb3duIHNlcGFyYXRlIHRhYmxlcy4gU28gaWYgYW55dGhpbmcgaXQgcmVxdWlyZXMgYSBi aXQgb2YgY2xlYW51cCB3b3JrLg0KDQpTbyB5b3UgYXJlIHNheWluZyBTQUZJIDQgd291bGQgb25s eSBhcHBseSB0byBJTE0gYW5kIG5vdCBOSExGRSB3aGVuIHRoZSBzYW1lIHByZWZpeCBpcyBhZHZl cnRpc2VkIGluIGJvdGggU0FGSSAxIGFuZCBTQUZJIDQ/IE1heWJlIEkgYW0gbWlzc2luZyBzb21l dGhpbmcgYnV0IEkgZG9u4oCZdCBzZWUgdGhhdCB0aGlzIGlzIHVzZWZ1bCBkZXBsb3ltZW50LiBJ biBhbnkgZXZlbnQsIHRoZSBub24tYmFja3dhcmQgY29tcGF0aWJsZSBiZWhhdmlvciB5b3UgYXJl IHByb3Bvc2luZyB3b3VsZCBiZSBiZXR0ZXIgc2VydmVkIGluIGEgc2VwYXJhdGUgZHJhZnQgdGhh biB0byBidXJkZW4gUkZDIDMxMDcgQklTLg0KDQoNCk1haW4gbW90aXZhdGlvbiBoZXJlIHdvdWxk IGJlIHRvIGhlbHAgbmV3IHZlbmRvcnMgdG8gbWFrZSB0aGUgdW5pZmllZCBjaG9pY2UgaW4gaG93 IHRoZXkgd2lsbCBpbXBsZW1lbnQgMzEwN2JpcyBzbyBsb25nIHRlcm0gd2UgZ2V0IHNvbWUgY29u c2lzdGVudCB3YXkgU0FGSSA0IGlzIGRlbGl2ZXJlZC4gQW5kIGlmIG5vdyBhdCB0aGUgImJpcyIg cmZjIGlzIG5vdCBhIGdvb2QgdGltZSB0aGVuIHdoYXQgeW91IGFyZSByZWFsbHkgYWR2b2NhdGlu ZyBpcyB0byBzdGF5IGZvciB5ZWFycyB0byBjb21lIHdpdGggc3VjaCB1bmRlZmluZWQgcmFuZG9t bmVzcyBhY3Jvc3MgaW1wbGVtZW50YXRpb25zLg0KDQpJIGFncmVlIHdpdGggdGhlIGN1cnJlbnQg ZHJhZnQgdGhhdCBpdCBzaG91bGQgYmUgbG9jYWwgcG9saWN5LiBJIGRvbuKAmXQgdGhpbmsgeW91 IGNhbiBhc3N1bWUgdGhhdCBldmVyeW9uZSBhZ3JlZXMgdGhhdCB0aGlzIHNob3VsZCBiZSBzcGVj aWZpZWQgYW5kIHRoYXQgeW91ciB2aWV3IG9uIGhvdyBpdCBzaG91bGQgd29yayBpcyBjb25zZW5z dXMuIEhlbmNlLCBwdXQgaXQgaW4gYSBzZXBhcmF0ZSBkcmFmdC4NCg0KDQpPdGhlciB0aGVuIGNv bnNpc3RlbmN5IEkgYWxzbyBzZWUgZm9sa3MgdHJ5aW5nIHRvIHVzZSBsYWJlbGVkIEJHUCBhcyBj b250cm9sbGVyIHRvIG5ldHdvcmsgZGV2aWNlIHByb3RvY29sIHRvIGluc3RhbGwgbGFiZWxzLiBG b3IgdGhhdCB1c2UgY2FzZSBhbG9uZSBjb21wbGV0ZSBzZXBhcmF0aW9uIGZyb20gU0FGSSAxIGlz IHZlcnkgaGVscGZ1bC4NCg0KWW91IGhhdmUgYm90aCBJTE0gYW5kIE5ITEZFIHRvIGNvbnNpZGVy IGhlcmUuIEkgbG9vayBmb3J3YXJkIHRvIHJldmlld2luZyB5b3VyIGRyYWZ0IG9uIHRoaXMgdG9w aWMuIElmIHRoZXJlIGlzIGNvbnNlbnN1cywgbWVyZ2VyIHdpdGggdGhlIGRyYWZ0IHVuZGVyIFdH IGFkb3B0aW9uIGNhbiBiZSBjb25zaWRlcmVkLg0KDQpUaGFua3MsDQpBY2VlDQoNCg0KDQoNClRo eCwNClIuDQoNCg0KDQpPbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCA0OjE1IFBNLCBBY2VlIExpbmRl bSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0K SGkgUm9iZXJ0LA0KDQpDdXJyZW50bHksIGV2ZXJ5dGhpbmcgaW4gZHJhZnQtcm9zZW4tbXBscy1y ZmMzMTA3YmlzIGlzIHByZXR0eSBtdWNoIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBvdXIgbW9y ZSB0aGFuIGEgZGVjYWRlIG9sZCBSRkMgMzEwNyBpbXBsZW1lbnRhdGlvbnMgYW5kIGRlcGxveW1l bnRzLiBXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIGlzIG5vdCBhbmQgaGFzIGltcGxpY2F0aW9ucyBp biBib3RoIHRoZSBjb250cm9sIGFuZCBmb3J3YXJkaW5nIHBsYW5lcy4gSWYgeW91IHJlYWxseSBi ZWxpZXZlIHRoYXQgdGhpcyBpcyDigJx0aGUgYmlnZ2VzdCBpc3N1ZSIsIEnigJlkIHN1Z2dlc3Qg eW91IGFydGljdWxhdGUgaXQgaW4gYSBzZXBhcmF0ZSBkcmFmdCB3aXRoIGNvbmNyZXRlIHVzZSBj YXNlcyBmb3IgaGF2aW5nIHNlcGFyYXRlIElQIGFuZCBNUExTIHRvcG9sb2dpZXMgZm9yIHRoZSBz YW1lIHNldCBvZiBwcmVmaXhlcy4gVGhlbiB0aGUgV0dzIGNhbiBldmFsdWF0ZSB0aGUgcmVxdWly ZW1lbnQgYW5kIHByb3Bvc2VkIHNvbHV0aW9uIGluZGVwZW5kZW50IG9mIFJGQyAzMTA3IEJJUy4N Cg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBSb2JlcnQgUmFzenVrIDxy b2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KRGF0ZTogV2VkbmVz ZGF5LCBBdWd1c3QgMzEsIDIwMTYgYXQgNToyNCBBTQ0KVG86IEVyaWMgQyBSb3NlbiA8ZXJvc2Vu QGp1bmlwZXIubmV0PG1haWx0bzplcm9zZW5AanVuaXBlci5uZXQ+Pg0KQ2M6IElEUiBMaXN0IDxp ZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+LCAibXBsc0BpZXRmLm9yZzxtYWlsdG86 bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPj4sICJi ZXNzQGlldGYub3JnPG1haWx0bzpiZXNzQGlldGYub3JnPiIgPGJlc3NAaWV0Zi5vcmc8bWFpbHRv OmJlc3NAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFttcGxzXSBbSWRyXSBGd2Q6IFdvcmtpbmcg R3JvdXAgYWRvcHRpb24gcG9sbCBvbiBkcmFmdC1yb3Nlbi1tcGxzLXJmYzMxMDdiaXMNCg0KSGkg RXJpYywNCg0KV2hpbGUgYWRvcHRpb24gY2FsbCBpcyBzb3J0IG9mIGVuY291cmFnZW1lbnQgZm9y IGZ1cnRoZXIgaW5wdXQgYmVmb3JlIEkgcmVzcG9uZCB0byBMb2EncyBtYWlsIEkgd291bGQgbGlr ZSB0byBnZXQgb25lIGFkZGl0aW9uYWwgYW5zd2VyIGZyb20gMzEwN2JpcyBhdXRob3JzIGFuZCBX R3MgbWVtYmVycy4NCg0KVGhvc2Ugd2hvIHNwZW5kIHllYXJzIGluIG1wbHMgZGVwbG95bWVudCBr bm93IHF1aXRlIHdlbGwgdGhhdCB0aGUgYmlnZ2VzdCBpc3N1ZSB3aXRoIHRvZGF5J3MgMzEwNyBk ZXBsb3ltZW50IGlzIGxhY2sgb2YgdGhlIGNsZWFyIGRlZmluaXRpb24gb2YgaXRzIGludGVyYWN0 aW9uIHdpdGggU0FGSS0xLiBXaGlsZSBvbmUgd291bGQgaG9wZSB0aGF0IDMxMDdiaXMgd2l0aCBu ZXcgY2FwYWJpbGl0eSB3aWxsIGNsZWFuIHRoaXMgbWVzcyBzZWN0aW9uIDUgb2YgeW91ciBkb2N1 bWVudCByYXRoZXIgc3dlZXBzIGl0IGFsbCB1bmRlciB0aGUgY2FycGV0IHN0YXRpbmcgdGhhdCBp dCBpcyBqdXN0IGxvY2FsIHBvbGljeS4gSU1PIGl0IGlzIG5vdCBhIG1hdHRlciBvZiBsb2NhbCBw b2xpY3kgbm9yIGl0IGlzIGltcGxlbWVudGF0aW9uIGRldGFpbC4NCg0KTG9jYWwgcG9saWN5IGNh biBiZSB0byBjaG9vc2Ugd2hpY2ggUklCIChvciBzZXF1ZW5jZSBvZiBSSUJzKSBzaG91bGQgYmUg dXNlZCBmb3IgcmVzb2x1dGlvbiBvZiBzcGVjaWZpYyBTQUZJcyBhbmQgbm90IGhvdyB0byBtaXgg U0FGSS0xIHdpdGggU0FGSS00LiBJdCdzIG5vdCBhIGxvY2FsIG1hdHRlciBhdCBhbGwgdG8gaGF2 ZSBkZXBsb3ltZW50IHJlc3VsdGluZyBpbiBpbmNvbnNpc3RlbnQgSUJHUCBiZXN0IHBhdGhzIGFj cm9zcyBnaXZlbiBkb21haW4uDQoNClRvIG1lIGNsZWFuZXN0IGlzIHRvIHNlcGFyYXRlIHRob3Nl IHR3byBTQUZJcyBjb21wbGV0ZWx5IGZyb20gZWFjaCBvdGhlciBieSB0aGUgc3BlYyBib3RoIGlu IEJHUCAoZG9uZSkgYXMgd2VsbCBhcyBsb2NhbCBSSUIgYW5kIEZJQi9MRklCLg0KDQpMaWtld2lz ZSBJIGRvIG5vdCBxdWl0ZSBhZ3JlZSB0aGF0IFNBRkktNCBzaG91bGQgYmUgImNvbnZlcnRpYmxl IiB0byBTQUZJLTEuIEFuZCB3ZSBhbGwgcmVhbGl6ZSB0aGF0IG9wcG9zaXRlIGRpcmVjdGlvbiBp cyByYXRoZXIgaGFyZC4NCg0KQW5vdGhlciBwZXJoYXBzIG1pbm9yIGNsYXJpZmljYXRpb24gd291 bGQgYmUgdG8gZ2V0IGFuIGV4cGxpY2l0IGNvbmZpcm1hdGlvbiB0aGF0IFNBRkktNCBjYW4gYmUg cmVjdXJzaXZlIG92ZXIgU0FGSS00IG9yIGZvciB0aGF0IG1hdHRlciBTQUZJLTEgKE1QTFMgaW4g R1JFIG9yIFNSIGluIElQKS4NCg0KVGh4LA0KUi4NCg0KDQo= --_000_D3ECD8487C9C7aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2JlcnQs Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0 OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9u ZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5H LUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBz b2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZsdDs8YSBocmVmPSJtYWls dG86cnJhc3p1a0BnbWFpbC5jb20iPnJyYXN6dWtAZ21haWwuY29tPC9hPiZndDsgb24gYmVoYWxm IG9mIFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCI+ cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgYXQgMTA6NDAgQU08 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5BY2VlIExpbmRl bSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIj5hY2VlQGNpc2NvLmNvbTwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+RXJpYyBD IFJvc2VuICZsdDs8YSBocmVmPSJtYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0Ij5lcm9zZW5AanVu aXBlci5uZXQ8L2E+Jmd0OywgSURSIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5v cmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRm Lm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGll dGYub3JnIj5tcGxzQGlldGYub3JnPC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmJl c3NAaWV0Zi5vcmciPmJlc3NAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW21wbHNdIFtJZHJdIEZ3ZDogV29y a2luZyBHcm91cCBhZG9wdGlvbiBwb2xsIG9uIGRyYWZ0LXJvc2VuLW1wbHMtcmZjMzEwN2Jpczxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KSGkgQWNl ZSw8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClRoZXJlIGlzIG5vIGlzc3VlIGZv ciBjb21wYXRpYmlsaXR5IGFzIG5ldyBwcm9wb3NhbCBoYXMgaXRzIG5ldyBCR1AgY2FwYWJpbGl0 eSBoZW5jZSB0aGVyZSBpcyBubyBpc3N1ZSB3aXRoIGRlcGxveWluZyBpdCBncmFkdWFsbHkuJm5i c3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgY3VycmVudCBjYXBhYmlsaXR5IGlzIHNwZWNp ZmljIHRvIHN1cHBvcnQgb2YgbXVsdGlwbGUgbGFiZWxzIC0gbm90IHlvdXIgcGFyb2NoaWFsIHZp ZXcgb24gdGhlIGludGVyYWN0aW9uIGJldHdlZW4gU0FGSXMuIEFyZSB5b3Ugc3VnZ2VzdGluZyBh IHNlY29uZCBjYXBhYmlsaXR5PyBBbGwgdGhlIG1vcmUgcmVhc29uIGZvciBhIHNlcGFyYXRlIGRy YWZ0LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxP Q0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAw IDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpZZXMgaXQgcmVxdWlyZXMgbmV3IFJJQiB3b3JrIGZv ciB0aG9zZSBpbXBsZW1lbnRhdGlvbnMgd2hpY2ggdG9kYXkgdXNlIHNpbmdsZSBSSUIgZm9yIGJv dGggU0FGSSAxIGFuZCBTQUZJIDQuIEZJQiBhbmQgTEZJQiBhcmUgYWxyZWFkeSBzZXBhcmF0ZS4g RWFjaCBTQUZJIGluIEJHUCBhbHNvIG5vcm1hbGx5IGhhcyBpdCdzIG93biBzZXBhcmF0ZSB0YWJs ZXMuIFNvIGlmIGFueXRoaW5nIGl0IHJlcXVpcmVzIGEgYml0IG9mIGNsZWFudXAgd29yay4mbmJz cDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNvIHlvdSBhcmUgc2F5aW5nIFNBRkkgNCB3b3VsZCBv bmx5IGFwcGx5IHRvIElMTSBhbmQgbm90IE5ITEZFIHdoZW4gdGhlIHNhbWUgcHJlZml4IGlzIGFk dmVydGlzZWQgaW4gYm90aCBTQUZJIDEgYW5kIFNBRkkgND8gTWF5YmUgSSBhbSBtaXNzaW5nIHNv bWV0aGluZyBidXQgSSBkb27igJl0IHNlZSB0aGF0IHRoaXMgaXMgdXNlZnVsIGRlcGxveW1lbnQu IEluIGFueSBldmVudCwgdGhlIG5vbi1iYWNrd2FyZCBjb21wYXRpYmxlIGJlaGF2aW9yDQogeW91 IGFyZSBwcm9wb3Npbmcgd291bGQgYmUgYmV0dGVyIHNlcnZlZCBpbiBhIHNlcGFyYXRlIGRyYWZ0 IHRoYW4gdG8gYnVyZGVuIFJGQyAzMTA3IEJJUy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1 YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KTWFpbiBt b3RpdmF0aW9uIGhlcmUgd291bGQgYmUgdG8gaGVscCBuZXcgdmVuZG9ycyB0byBtYWtlIHRoZSB1 bmlmaWVkIGNob2ljZSBpbiBob3cgdGhleSB3aWxsIGltcGxlbWVudCAzMTA3YmlzIHNvIGxvbmcg dGVybSB3ZSBnZXQgc29tZSBjb25zaXN0ZW50IHdheSBTQUZJIDQgaXMgZGVsaXZlcmVkLiBBbmQg aWYgbm93IGF0IHRoZSAmcXVvdDtiaXMmcXVvdDsgcmZjIGlzIG5vdCBhIGdvb2QgdGltZSB0aGVu IHdoYXQgeW91IGFyZSByZWFsbHkgYWR2b2NhdGluZyBpcw0KIHRvIHN0YXkgZm9yIHllYXJzIHRv IGNvbWUgd2l0aCBzdWNoIHVuZGVmaW5lZCByYW5kb21uZXNzIGFjcm9zcyBpbXBsZW1lbnRhdGlv bnMuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFncmVlIHdpdGggdGhlIGN1cnJlbnQg ZHJhZnQgdGhhdCBpdCBzaG91bGQgYmUgbG9jYWwgcG9saWN5LiBJIGRvbuKAmXQgdGhpbmsgeW91 IGNhbiBhc3N1bWUgdGhhdCBldmVyeW9uZSBhZ3JlZXMgdGhhdCB0aGlzIHNob3VsZCBiZSBzcGVj aWZpZWQgYW5kIHRoYXQgeW91ciB2aWV3IG9uIGhvdyBpdCBzaG91bGQgd29yayBpcyBjb25zZW5z dXMuIEhlbmNlLCBwdXQgaXQgaW4gYSBzZXBhcmF0ZSBkcmFmdC4mbmJzcDs8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVv dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVIt TEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs dCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6 ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwi Pg0KT3RoZXIgdGhlbiBjb25zaXN0ZW5jeSBJIGFsc28gc2VlIGZvbGtzIHRyeWluZyB0byB1c2Ug bGFiZWxlZCBCR1AgYXMgY29udHJvbGxlciB0byBuZXR3b3JrIGRldmljZSBwcm90b2NvbCB0byBp bnN0YWxsIGxhYmVscy4gRm9yIHRoYXQgdXNlIGNhc2UgYWxvbmUgY29tcGxldGUgc2VwYXJhdGlv biBmcm9tIFNBRkkgMSBpcyB2ZXJ5IGhlbHBmdWwuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5Zb3UgaGF2ZSBib3RoIElMTSBhbmQgTkhMRkUgdG8gY29uc2lkZXIgaGVyZS4gSSBsb29rIGZv cndhcmQgdG8gcmV2aWV3aW5nIHlvdXIgZHJhZnQgb24gdGhpcyB0b3BpYy4gSWYgdGhlcmUgaXMg Y29uc2Vuc3VzLCBtZXJnZXIgd2l0aCB0aGUgZHJhZnQgdW5kZXIgV0cgYWRvcHRpb24gY2FuIGJl IGNvbnNpZGVyZWQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3Ms PC9kaXY+DQo8ZGl2PkFjZWUmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9U RSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsg TUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQpUaHgsPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXpl OnNtYWxsIj4NClIuPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxi cj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCA0OjE1IFBNLCBBY2VlIExpbmRlbSAo YWNlZSkgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmFjZWVAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxi cj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBz dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRw eDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj5IaSBSb2JlcnQsJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DdXJyZW50bHksIGV2ZXJ5dGhpbmcgaW4g ZHJhZnQtcm9zZW4tbXBscy1yZmMzMTA3YmlzIGlzIHByZXR0eSBtdWNoIGJhY2t3YXJkIGNvbXBh dGlibGUgd2l0aCBvdXIgbW9yZSB0aGFuIGEgZGVjYWRlIG9sZCBSRkMgMzEwNyBpbXBsZW1lbnRh dGlvbnMgYW5kIGRlcGxveW1lbnRzLiBXaGF0IHlvdSBhcmUgcHJvcG9zaW5nIGlzIG5vdCBhbmQg aGFzIGltcGxpY2F0aW9ucyBpbiBib3RoIHRoZSBjb250cm9sIGFuZCBmb3J3YXJkaW5nIHBsYW5l cy4NCiBJZiB5b3UgcmVhbGx5IGJlbGlldmUgdGhhdCB0aGlzIGlzIOKAnHRoZSBiaWdnZXN0IGlz c3VlJnF1b3Q7LCBJ4oCZZCBzdWdnZXN0IHlvdSBhcnRpY3VsYXRlIGl0IGluIGEgc2VwYXJhdGUg ZHJhZnQgd2l0aCBjb25jcmV0ZSB1c2UgY2FzZXMgZm9yIGhhdmluZyBzZXBhcmF0ZSBJUCBhbmQg TVBMUyB0b3BvbG9naWVzIGZvciB0aGUgc2FtZSBzZXQgb2YgcHJlZml4ZXMuIFRoZW4gdGhlIFdH cyBjYW4gZXZhbHVhdGUgdGhlIHJlcXVpcmVtZW50IGFuZCBwcm9wb3NlZA0KIHNvbHV0aW9uIGlu ZGVwZW5kZW50IG9mIFJGQyAzMTA3IEJJUy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxzcGFuPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTFwdDt0 ZXh0LWFsaWduOmxlZnQ7Y29sb3I6YmxhY2s7Qk9SREVSLUJPVFRPTTptZWRpdW0gbm9uZTtCT1JE RVItTEVGVDptZWRpdW0gbm9uZTtQQURESU5HLUJPVFRPTTowaW47UEFERElORy1MRUZUOjBpbjtQ QURESU5HLVJJR0hUOjBpbjtCT1JERVItVE9QOiNiNWM0ZGYgMXB0IHNvbGlkO0JPUkRFUi1SSUdI VDptZWRpdW0gbm9uZTtQQURESU5HLVRPUDozcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkZyb206IDwvc3Bhbj5tcGxzICZsdDs8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg b24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFz enVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSwgQXVn dXN0IDMxLCAyMDE2IGF0IDU6MjQgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+VG86IDwvc3Bhbj5FcmljIEMgUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzplcm9zZW5AanVu aXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5lcm9zZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPklEUiBMaXN0ICZsdDs8 YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWRyQGlldGYub3Jn PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bXBsc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBo cmVmPSJtYWlsdG86YmVzc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJlc3NAaWV0Zi5vcmc8 L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpiZXNzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+YmVzc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW21wbHNdIFtJZHJdIEZ3ZDogV29ya2luZyBHcm91 cCBhZG9wdGlvbiBwb2xsIG9uIGRyYWZ0LXJvc2VuLW1wbHMtcmZjMzEwN2Jpczxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iQk9SREVSLUxFRlQ6I2I1YzRkZiA1IHNvbGlkO1BBRERJTkc6MCAwIDAgNTtNQVJH SU46MCAwIDAgNSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpIaSBFcmljLDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6 c21hbGwiPg0KV2hpbGUgYWRvcHRpb24gY2FsbCBpcyBzb3J0IG9mIGVuY291cmFnZW1lbnQgZm9y IGZ1cnRoZXIgaW5wdXQgYmVmb3JlIEkgcmVzcG9uZCB0byBMb2EncyBtYWlsIEkgd291bGQgbGlr ZSB0byBnZXQgb25lIGFkZGl0aW9uYWwgYW5zd2VyIGZyb20gMzEwN2JpcyBhdXRob3JzIGFuZCBX R3MgbWVtYmVycy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwi Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClRob3Nl IHdobyBzcGVuZCB5ZWFycyBpbiBtcGxzIGRlcGxveW1lbnQga25vdyBxdWl0ZSB3ZWxsIHRoYXQg dGhlIGJpZ2dlc3QgaXNzdWUgd2l0aCB0b2RheSdzIDMxMDcgZGVwbG95bWVudCBpcyBsYWNrIG9m IHRoZSBjbGVhciBkZWZpbml0aW9uIG9mIGl0cyBpbnRlcmFjdGlvbiB3aXRoIFNBRkktMS4gV2hp bGUgb25lIHdvdWxkIGhvcGUgdGhhdCAzMTA3YmlzIHdpdGggbmV3IGNhcGFiaWxpdHkgd2lsbCBj bGVhbiB0aGlzIG1lc3Mgc2VjdGlvbiA1DQogb2YgeW91ciBkb2N1bWVudCByYXRoZXIgc3dlZXBz IGl0IGFsbCB1bmRlciB0aGUgY2FycGV0IHN0YXRpbmcgdGhhdCBpdCBpcyBqdXN0IGxvY2FsIHBv bGljeS4gSU1PIGl0IGlzIG5vdCBhIG1hdHRlciBvZiBsb2NhbCBwb2xpY3kgbm9yIGl0IGlzIGlt cGxlbWVudGF0aW9uIGRldGFpbC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1 bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNp emU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs Ij4NCkxvY2FsIHBvbGljeSBjYW4gYmUgdG8gY2hvb3NlIHdoaWNoIFJJQiAob3Igc2VxdWVuY2Ug b2YgUklCcykgc2hvdWxkIGJlIHVzZWQgZm9yIHJlc29sdXRpb24gb2Ygc3BlY2lmaWMgU0FGSXMg YW5kIG5vdCBob3cgdG8gbWl4IFNBRkktMSB3aXRoIFNBRkktNC4gSXQncyBub3QgYSBsb2NhbCBt YXR0ZXIgYXQgYWxsIHRvIGhhdmUgZGVwbG95bWVudCByZXN1bHRpbmcgaW4gaW5jb25zaXN0ZW50 IElCR1AgYmVzdCBwYXRocyBhY3Jvc3MgZ2l2ZW4gZG9tYWluLiZuYnNwOzwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp Zjtmb250LXNpemU6c21hbGwiPg0KVG8gbWUgY2xlYW5lc3QgaXMgdG8gc2VwYXJhdGUgdGhvc2Ug dHdvIFNBRklzIGNvbXBsZXRlbHkgZnJvbSBlYWNoIG90aGVyIGJ5IHRoZSBzcGVjIGJvdGggaW4g QkdQIChkb25lKSBhcyB3ZWxsIGFzIGxvY2FsIFJJQiBhbmQgRklCL0xGSUIuJm5ic3A7PC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpMaWtld2lzZSBJIGRvIG5vdCBxdWl0ZSBhZ3Jl ZSB0aGF0IFNBRkktNCBzaG91bGQgYmUgJnF1b3Q7Y29udmVydGlibGUmcXVvdDsgdG8gU0FGSS0x LiBBbmQgd2UgYWxsIHJlYWxpemUgdGhhdCBvcHBvc2l0ZSBkaXJlY3Rpb24gaXMgcmF0aGVyIGhh cmQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpBbm90aGVyIHBlcmhh cHMgbWlub3IgY2xhcmlmaWNhdGlvbiB3b3VsZCBiZSB0byBnZXQgYW4gZXhwbGljaXQgY29uZmly bWF0aW9uIHRoYXQgU0FGSS00IGNhbiBiZSByZWN1cnNpdmUgb3ZlciBTQUZJLTQgb3IgZm9yIHRo YXQgbWF0dGVyIFNBRkktMSAoTVBMUyBpbiBHUkUgb3IgU1IgaW4gSVApLiZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KVGh4LDxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpSLjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs dCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6 ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D3ECD8487C9C7aceeciscocom_-- From nobody Wed Aug 31 16:52:43 2016 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 AFFB612D7AF; Wed, 31 Aug 2016 16:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.068 X-Spam-Level: X-Spam-Status: No, score=-15.068 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 rDNx39XTEdNC; Wed, 31 Aug 2016 16:52:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0869312D1A4; Wed, 31 Aug 2016 16:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10681; q=dns/txt; s=iport; t=1472687555; x=1473897155; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=nUqpz3hEvORryrgvKGcKqF4zoz33pm4zl7+vnZ8dZxI=; b=HFlqMjO6tyaHNJ7gf/i12SXqMqLTp2aUO/76ZfoADQMvGYtu8Iy3gDBn uI3e1ZCrb+P8xaG09S+Tm1eSm5HU3H1oXXP0usLmj1cml5Ku6ZXIJCrsg aUvli7JcTLPnZxGZUIraSPi8LIo3Ar9+sRGzl3pSofrVxTjP8pBvTrPLV c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHAgCObMdX/5NdJa1dgx0zAQEBAQEeV?= =?us-ascii?q?3wHsxSFDYIBJIV4AhyBLTgUAQIBAQEBAQEBXieEYQEBBQEBIUgDGQICAQgRAwE?= =?us-ascii?q?CKAMCAgIZDAsUCQgCBAESiEgOrl+McgEBAQEBAQEBAQEBAQEBAQEBAQEBARcFB?= =?us-ascii?q?Yp3hBIRASIRCRaCTIJaBZlQAY8wgW2EXYkNjEiDeAEeNoJ8gTVwhE2BIH8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,264,1470700800"; d="scan'208,217";a="142184941" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2016 23:52:34 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u7VNqXbI008632 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 23:52:34 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 19:52:32 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 19:52:33 -0400 From: "Acee Lindem (acee)" To: Loa Andersson , "idr@ietf.org" , "bess@ietf.org" Thread-Topic: [Idr] Fwd: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis Thread-Index: AQHSA+K9B0JSxsuCGk2Zx4Q7BFcHng== Date: Wed, 31 Aug 2016 23:52:32 +0000 Message-ID: References: <8A502F2D-E7EC-4497-9BF1-1295E1F21A02@pi.nu> In-Reply-To: <8A502F2D-E7EC-4497-9BF1-1295E1F21A02@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.198] Content-Type: multipart/alternative; boundary="_000_D3ECE5BF7CA53aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Fwd: [mpls] Working Group adoption poll on draft-rosen-mpls-rfc3107bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 23:52:37 -0000 --_000_D3ECE5BF7CA53aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gY2FzZSBpdCBpcyBub3Qgb2J2aW91cywgSSBzdXBwb3J0IE1QTFMgV0cgYWRvcHRpb24gb2Yg dGhlIHN1YmplY3QgZHJhZnQgaW4gaXRzIGN1cnJlbnQgZm9ybSA7XikuIEkgYWxyZWFkeSBzdXBw b3J0ZWQgaXQgb24gdGhlIE1QTFMgbGlzdC4NClRoYW5rcywNCkFjZWUNCg0KRnJvbTogSWRyIDxp ZHItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhh bGYgb2YgTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+Pg0KRGF0ZTog V2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgYXQgMTI6MjggQU0NClRvOiBJRFIgTGlzdCA8aWRy QGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+PiwgImJlc3NAaWV0Zi5vcmc8bWFpbHRvOmJl c3NAaWV0Zi5vcmc+IiA8YmVzc0BpZXRmLm9yZzxtYWlsdG86YmVzc0BpZXRmLm9yZz4+DQpTdWJq ZWN0OiBbSWRyXSBGd2Q6IFttcGxzXSBXb3JraW5nIEdyb3VwIGFkb3B0aW9uIHBvbGwgb24gZHJh ZnQtcm9zZW4tbXBscy1yZmMzMTA3YmlzDQoNCldvcmtpbmcgR3JvdXBzLA0KDQpQbGVhc2Ugbm90 ZSB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwgZm9yIGRyYWZ0LXJvc2VuLW1w bHMtcmZjMzEwN2JpcyBoYXMgYmVlbiBzdGFydGVkIGluIHRoZSBtcGxzIHdnLiBQbGVhc2Ugc2Vu ZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLg0KDQovTG9hDQptcGxzIHdnIGNvLWNoYWlyDQoNClNl bnQgZnJvbSBteSBpUGhvbmUNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206IExv YSBBbmRlcnNzb24gPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4NCkRhdGU6IDMwIGF1Z3Vz dGkgMjAxNiAwODoxMDoxMyBHTVQrOA0KVG86ICJtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGll dGYub3JnPiIgPG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Pg0KQ2M6ICJkcmFm dC1yb3Nlbi1tcGxzLXJmYzMxMDdiaXMuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1yb3Nlbi1t cGxzLXJmYzMxMDdiaXMuYWxsQGlldGYub3JnPiIgPGRyYWZ0LXJvc2VuLW1wbHMtcmZjMzEwN2Jp cy5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXJvc2VuLW1wbHMtcmZjMzEwN2Jpcy5hbGxAaWV0 Zi5vcmc+PiwgIm1wbHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9y Zz4iIDxtcGxzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAaWV0Zi5vcmc+Pg0K U3ViamVjdDogW21wbHNdIFdvcmtpbmcgR3JvdXAgYWRvcHRpb24gcG9sbCBvbiBkcmFmdC1yb3Nl bi1tcGxzLXJmYzMxMDdiaXMNCg0KV29ya2luZyBHcm91cCwNCg0KVGhpcyBpcyB0byBzdGFydCBh IHR3byB3ZWVrIHBvbGwgb24gYWRvcHRpbmcgZHJhZnQtcm9zZW4tbXBscy1yZmMzMTA3YmlzDQph cyBhbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNClBsZWFzZSBzZW5kIHlvdXIgY29t bWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcNCmdyb3VwIG1h aWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLiBQbGVhc2Ug Z2l2ZSBhIHRlY2huaWNhbA0KbW90aXZhdGlvbiBmb3IgeW91ciBzdXBwb3J0L25vdCBzdXBwb3J0 LCBlc3BlY2lhbGx5IGlmIHlvdSB0aGluayB0aGF0DQp0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBi ZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4NCg0KVGhlcmUgYXJlIG5vIElQ UiBkaXNjbG9zdXJlcyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQoNCkFsbCB0aGUgYXV0aG9ycyBo YXMgc3RhdGVkIG9uIHRoZSBvbiB0aGUgbXBscyB3ZyBtYWlsaW5nIGxpc3QgdGhhdCB0aGV5DQph cmUgbm90IGF3YXJlIG9mIGFueSBJUFJzIHRoYXQgcmVsYXRlIHRvIHRoaXMgZG9jdW1lbnQuDQoN ClRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwgZW5kcyBTZXB0ZW1iZXIgMTQsIDIwMTYu DQoNCi9Mb2ENCg0KTVBMUyB3ZyBjby1jaGFpci4NCi0tDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAg ICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208bWFpbHRvOmxv YUBtYWlsMDEuaHVhd2VpLmNvbT4NClNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAg ICAgICAgICAgbG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+DQpIdWF3ZWkgVGVjaG5vbG9naWVz IChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQpt cGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo= --_000_D3ECE5BF7CA53aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <47FA3DA1FCA4404E8269473AF00D0961@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JbiBjYXNlIGl0 IGlzIG5vdCBvYnZpb3VzLCBJIHN1cHBvcnQgTVBMUyBXRyBhZG9wdGlvbiBvZiB0aGUgc3ViamVj dCBkcmFmdCBpbiBpdHMgY3VycmVudCBmb3JtIDteKS4gSSBhbHJlYWR5IHN1cHBvcnRlZCBpdCBv biB0aGUgTVBMUyBsaXN0LiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFj ZWU8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRl eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+SWRyICZsdDs8YSBocmVmPSJtYWls dG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlkci1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24g YmVoYWxmIG9mIExvYSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiPmxv YUBwaS5udTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6 IDwvc3Bhbj5XZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiBhdCAxMjoyOCBBTTxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPklEUiBMaXN0ICZsdDs8YSBocmVm PSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmJlc3NAaWV0Zi5vcmciPmJlc3NAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bSWRyXSBGd2Q6IFtt cGxzXSBXb3JraW5nIEdyb3VwIGFkb3B0aW9uIHBvbGwgb24gZHJhZnQtcm9zZW4tbXBscy1yZmMz MTA3YmlzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1 YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0K PGRpdiBkaXI9ImF1dG8iPg0KPGRpdj5Xb3JraW5nIEdyb3Vwcyw8L2Rpdj4NCjxkaXYgaWQ9IkFw cGxlTWFpbFNpZ25hdHVyZSI+PGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1 cmUiPlBsZWFzZSBub3RlIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gcG9sbCBmb3Ig ZHJhZnQtcm9zZW4tbXBscy1yZmMzMTA3YmlzIGhhcyBiZWVuIHN0YXJ0ZWQgaW4gdGhlIG1wbHMg d2cuIFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMgd2cgbWFpbGluZyBsaXN0 ICg8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4pLiZuYnNw OzwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+DQo8L2Rpdj4NCjxkaXYg aWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+L0xvYTwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2ln bmF0dXJlIj5tcGxzIHdnIGNvLWNoYWlyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTwv ZGl2Pg0KPGRpdj48YnI+DQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8YnI+DQo8YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48Yj5Gcm9tOjwvYj4gTG9hIEFuZGVy c3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSI+bG9hQHBpLm51PC9hPiZndDs8YnI+ DQo8Yj5EYXRlOjwvYj4gMzAgYXVndXN0aSAyMDE2IDA4OjEwOjEzIEdNVCYjNDM7ODxicj4NCjxi PlRvOjwvYj4gJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5v cmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQt cm9zZW4tbXBscy1yZmMzMTA3YmlzLmFsbEBpZXRmLm9yZyI+ZHJhZnQtcm9zZW4tbXBscy1yZmMz MTA3YmlzLmFsbEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1y b3Nlbi1tcGxzLXJmYzMxMDdiaXMuYWxsQGlldGYub3JnIj5kcmFmdC1yb3Nlbi1tcGxzLXJmYzMx MDdiaXMuYWxsQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptcGxzLWNo YWlyc0BpZXRmLm9yZyI+bXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhy ZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyI+bXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiA8Yj5bbXBsc10gV29ya2luZyBHcm91cCBhZG9wdGlv biBwb2xsIG9uIGRyYWZ0LXJvc2VuLW1wbHMtcmZjMzEwN2JpczwvYj48YnI+DQo8YnI+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5X b3JraW5nIEdyb3VwLDwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+VGhpcyBp cyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24gYWRvcHRpbmcgZHJhZnQtcm9zZW4tbXBscy1y ZmMzMTA3YmlzPC9zcGFuPjxicj4NCjxzcGFuPmFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1 bWVudC48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPlBsZWFzZSBzZW5kIHlv dXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmc8L3Nw YW4+PGJyPg0KPHNwYW4+Z3JvdXAgbWFpbGluZyBsaXN0ICg8YSBocmVmPSJtYWlsdG86bXBsc0Bp ZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4pLiBQbGVhc2UgZ2l2ZSBhIHRlY2huaWNhbDwvc3Bh bj48YnI+DQo8c3Bhbj5tb3RpdmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVz cGVjaWFsbHkgaWYgeW91IHRoaW5rIHRoYXQ8L3NwYW4+PGJyPg0KPHNwYW4+dGhlIGRvY3VtZW50 IHNob3VsZCBub3QgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuPC9zcGFu Pjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5UaGVyZSBhcmUgbm8gSVBSIGRpc2Nsb3N1 cmVzIGFnYWluc3QgdGhpcyBkb2N1bWVudC48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4N CjxzcGFuPkFsbCB0aGUgYXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRoZSBvbiB0aGUgbXBscyB3ZyBt YWlsaW5nIGxpc3QgdGhhdCB0aGV5PC9zcGFuPjxicj4NCjxzcGFuPmFyZSBub3QgYXdhcmUgb2Yg YW55IElQUnMgdGhhdCByZWxhdGUgdG8gdGhpcyBkb2N1bWVudC48L3NwYW4+PGJyPg0KPHNwYW4+ PC9zcGFuPjxicj4NCjxzcGFuPlRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwgZW5kcyBT ZXB0ZW1iZXIgMTQsIDIwMTYuPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4v TG9hPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5NUExTIHdnIGNvLWNoYWly Ljwvc3Bhbj48YnI+DQo8c3Bhbj4tLSA8L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxz cGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5Mb2EgQW5kZXJzc29uICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO2VtYWlsOiA8YSBocmVmPSJtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tIj4NCmxvYUBt YWlsMDEuaHVhd2VpLmNvbTwvYT48L3NwYW4+PGJyPg0KPHNwYW4+U2VuaW9yIE1QTFMgRXhwZXJ0 ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Im1haWx0bzpsb2FA cGkubnUiPmxvYUBwaS5udTwvYT48L3NwYW4+PGJyPg0KPHNwYW4+SHVhd2VpIFRlY2hub2xvZ2ll cyAoY29uc3VsdGFudCkgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGhvbmU6ICYjNDM7NDYgNzM5 IDgxIDIxIDY0PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5t cGxzIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86bXBsc0Bp ZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_D3ECE5BF7CA53aceeciscocom_--