X-List-Received-Date: Tue, 05 Jul 2016 19:25:30 -0000 --001a114a880839e9920536e86ae4 Content-Type: text/plain; charset=UTF-8 Hey All, We are looking for your comments on the new draft https://datatracker.ietf.org/doc/draft-bhagat-bgp-overload/ We would really appreciate any comments and questions about the document. Best Regards, Amit Bhagat --001a114a880839e9920536e86ae4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hey Al= l,

We ar= e looking for your comments on the new draft https://datatracker.ietf.org/doc/= draft-bhagat-bgp-overload/

We would really appreciate any comments and questions=
 about the document.
=20
Best Regards,

Amit Bhagat

--001a114a880839e9920536e86ae4-- From nobody Tue Jul 5 12:46: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 A3C2012D107 for ; Tue, 5 Jul 2016 12:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, 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=unavailable 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 scuqMbS9Ie7i for ; Tue, 5 Jul 2016 12:46:09 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 57D6812D1AF for ; Tue, 5 Jul 2016 12:39:12 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id h129so141549809lfh.1 for ; Tue, 05 Jul 2016 12:39:12 -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=0Y2Gh5liNsnJaT3APEC8rudnnim3kDSFAj++V5+N6Rs=; b=V+pcuEXVBx2gpK14gAaeFLOoIQqGqffiR+LubaAFinwhU1i82MEUVgjT4IgDxLAAb4 jhZY9vPvmZaVvZL+/bgSsEutjooF9xuPK5biTVC0MezIzMKzKgmvMAfI2xgPgT9ES5JU s8Qjgx7jQA07N6i+KsnCNwHQjm68CpDhrYesn9Kw8yVAEsDSDXTjjA1zcA+na0DeUYGh hEaeLOej2hO0IhMVJp1VOEXhmgkPuG3wJgbCVbv5vWK70AEy2KZ3Tijomd1qCArctpNM l96csU9jc9JTJzyTi6Xfk88DdmZM8+RPSLLE6rYn6D6+JoYl3WWLSsbVSdziqc8Fdhkk XrUA== 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=0Y2Gh5liNsnJaT3APEC8rudnnim3kDSFAj++V5+N6Rs=; b=NAS5jMerxFALecPWx2QOxjNoQkoqroeIqewX5uZUV/4elHbZ7mlLEjFg9/6ZHJYkpN h/f0RhAoHDnkgJq3Bm9FRqoGeXsdS/kKSQB5qT5Mk+4L4T9sMunDdt8Mq5hZVu63wiXB sqp1wXlNeG1GfG6DybDVxc8paxJPKP/MfTSplogOB+04xeez97S5rIO+egtGIsaWMeLc qqoREqSr4TiRzRrBFGGPRxZ1MZxFqkJ87XP2TTlRxEPK+AvmtnPtlJ8WLbNAqnEB1HZZ dEUbTgPQIuL1x2PJ1P4D9xKlr56iCb883/eMRlIc81h2+P+YlHNhJnZ89UXqlD/HVmVW MuFw== X-Gm-Message-State: ALyK8tII0oP3ZeFDHuCKgVXt+uPLMXptFc9KjRwkc/vPWxNAOLO7OuSdwIt9ex8nzMtDdIi3yQNjBpeqv/7I/g== X-Received: by 10.46.5.138 with SMTP id 132mr4795533ljf.9.1467747550501; Tue, 05 Jul 2016 12:39:10 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Tue, 5 Jul 2016 12:39:09 -0700 (PDT) In-Reply-To: References: From: Robert Raszuk Date: Tue, 5 Jul 2016 21:39:09 +0200 X-Google-Sender-Auth: z2jwfNl8LIiVjKx5EGf9ew3WOus Message-ID: To: amit bhagat Content-Type: multipart/alternative; boundary=001a114a733c5e20d00536e89bc5 Archived-At: Cc: idr wg Subject: Re: [Idr] Review Request for draft BGP Overload 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, 05 Jul 2016 19:46:11 -0000 --001a114a733c5e20d00536e89bc5 Content-Type: text/plain; charset=UTF-8 Hi Amit, In an essence it seems that your proposal is just a subset of "Graceful BGP session shutdown" https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06. Can you clarify how your encoding is any better then proposed by Pierre's, et al. G-Shut community? Why do you need a new SAFI for it ? Would it be easier to use community or attribute and send it over existing SAFIs ? How in your encoding one can distinguish IBGP sessions from EBGP sessions (case of core or edge line card replacement) ? What is the use case to not use "global" mode .. ie. when do you envision need to signal overload for only subset of AFI/SAFIs carried by given BGP speaker ? Many Thx, Robert. On Tue, Jul 5, 2016 at 9:25 PM, amit bhagat wrote: > Hey All, > > We are looking for your comments on the new draft > https://datatracker.ietf.org/doc/draft-bhagat-bgp-overload/ > > We would really appreciate any comments and questions about the document. > > Best Regards, > > Amit Bhagat > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a114a733c5e20d00536e89bc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Amit,

In an essence it seems that your proposal is just a = subset of "Graceful BGP session shutdown"= =C2=A0https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06.=C2=A0<= /div>

Can you clarify how yo= ur encoding is any better then proposed by Pierre's, et al. G-Shut comm= unity?=C2=A0

Why do yo= u need a new SAFI for it ? Would it be easier to use community or attribute= and send it over existing SAFIs ?=C2=A0

How in your encoding one can distinguish IBGP sessions f= rom EBGP sessions (case of core or edge line card replacement) ?=C2=A0

What is the use case to no= t use "global" mode .. ie. when do you envision need to signal ov= erload for only subset of AFI/SAFIs carried by given BGP speaker ?

Many Thx,
Robert.

On Tue, Jul 5, 2016 at 9:25 PM, amit bhagat <scet.amit@gma= il.com> wrote:

Hey All,

We are looking fo= r your comments on the new draft https://datatracker.ietf.or= g/doc/draft-bhagat-bgp-overload/
We would really appreciate any comments and que=
stions about the document.
=20
Best Regards,
Amit Bhagat
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--001a114a733c5e20d00536e89bc5-- From nobody Tue Jul 5 15:12: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 B2D3212D0FC for ; Tue, 5 Jul 2016 15:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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 YMzqj1JctlnB for ; Tue, 5 Jul 2016 15:12:50 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 2905D12B05B for ; Tue, 5 Jul 2016 15:12:50 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id w59so108386329qtd.3 for ; Tue, 05 Jul 2016 15:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N+RRo9COZe1xK5SDynWyJPu3iU63gWSJb2AgjNa5YFU=; b=IpReQ+aReWn0tRAYXk1vlphS6bt5pObCfm9YDw4IQ1lUzCtbHF7i884ijLcn9ysOyV SAGBLlmRfmuvXxYvIZDK9ioOXa0vAYk0BrDycM/5RYz5LvSLouIuf3fxQ/b/uK3S2BTd 8+2Zv0tnREkhUzzpPjWzo/lMIeUYGAXnmBve6SqSnZ2/CoJ7ctQsXDnBwOQunkE68f2A uMMm4+aEjd/hlPE5yGMk9Hf6F+mMpoEgflCmYDtjMl4p9fWW7r65mjieNWb+CI1ZdfcX I7tYJJ3z0PmGsSE0vlEJMRMN3b/jTtWK2W2ylQ4bX2GcPfrT8MSZ/BUZgD9+g/BY8huX cLhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N+RRo9COZe1xK5SDynWyJPu3iU63gWSJb2AgjNa5YFU=; b=l2RMc1CpKIxWDCKS1joUEF0GPCXXvAGJvXkz+rqu81QXQQxGSpsm9DIObgjOpBUWYh 2FQAJ/snw29LOFLyEraReLwJT8sm0I07ntMMora3hvPyzgeNzKjsMYHYmiUhDNxOA0Qx ViQ0CBoM5raAhb3AowzGYKRh298G39uDI5xVJECjoPM3ZRNQDSDTGJAMHBoN9x3eVCNy Gukv24jJyTfzCkMGVLRCEenWnc1ip04Dnlt/cL4zROewjP6i/Cb0CyLvQWdR6fhZ3Lbn +iK/X9mhXncsGW3Z3iSyA2BIZ96WTQk28s2EOXzgQdINTpreGakFpTRyeP3b4K1qDWLg g2Xw== X-Gm-Message-State: ALyK8tI3clP29H7RRbQcIzXhkLjSAE/Gx6mfAC4CYRlvMem3BbQVP8hGAj3EUbfZrj1U+Qg8N2bu0JcB81szgg== X-Received: by 10.200.49.165 with SMTP id h34mr31129188qte.43.1467756769325; Tue, 05 Jul 2016 15:12:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.43.232 with HTTP; Tue, 5 Jul 2016 15:12:48 -0700 (PDT) In-Reply-To: References:

From: amit bhagat Date: Tue, 5 Jul 2016 15:12:48 -0700 Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary=001a11c10850da391e0536eac0c7 Archived-At: Cc: idr wg Subject: Re: [Idr] Review Request for draft BGP Overload 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, 05 Jul 2016 22:12:53 -0000 --001a11c10850da391e0536eac0c7 Content-Type: text/plain; charset=UTF-8 Hi Robert, Many thanks for your comments. Initially, I thought about using a community but that would mean putting all NLRIs in the Update message. This could also mean a different Update per-neighbor/per-peergroup. re: G-shut community - Reading through G-shut draft, it seems to be targeting a single use case - maintenance. Additionally, it requires manual configuration of route-policies. The way I envision this is a simple Update that is applicable to all peers; no need to worry about manipulating any BGP attributes. re: new SAFI - The reason for requesting a new SAFI is so that a new NLRI encoding can be defined to keep it simple. The existing SAFI would require adding NLRIs to the Update message. re: BGP session distinction - Is there a need to identify IBGP or EBGP session? Perhaps I am missing something. re: Global mode - the use case would be if a BGP speaker has multiple links to different peers and running different AFI/SAFI pairs per links, it might be just easy to drain a particular type of traffic rather than ALL traffic. Additionally, one of the other use cases I am thinking of is when a BGP speaker drops its Established neighbor-count below a threshold, it can advertise itself as "Overloaded". This can help avoid congestion. Agreed, this can also be the cause of network outage, but within a CLOS fabric, it should not be a problem due to multiple paths. Again, thanks for reviewing. Amit. On Tue, Jul 5, 2016 at 12:39 PM, Robert Raszuk wrote: > Hi Amit, > > In an essence it seems that your proposal is just a subset of "Graceful > BGP session shutdown" > https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06. > > Can you clarify how your encoding is any better then proposed by Pierre's, > et al. G-Shut community? > > Why do you need a new SAFI for it ? Would it be easier to use community or > attribute and send it over existing SAFIs ? > > How in your encoding one can distinguish IBGP sessions from EBGP sessions > (case of core or edge line card replacement) ? > > What is the use case to not use "global" mode .. ie. when do you envision > need to signal overload for only subset of AFI/SAFIs carried by given BGP > speaker ? > > Many Thx, > Robert. > > > On Tue, Jul 5, 2016 at 9:25 PM, amit bhagat wrote: > >> Hey All, >> >> We are looking for your comments on the new draft >> https://datatracker.ietf.org/doc/draft-bhagat-bgp-overload/ >> >> We would really appreciate any comments and questions about the document. >> >> Best Regards, >> >> Amit Bhagat >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> > --001a11c10850da391e0536eac0c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Robert,

Many than= ks for your comments.

Initially, I thought about using a commu= nity but that would mean putting all NLRIs in the Update message. This coul= d also mean a different Update per-neighbor/per-peergroup.

re:= G-shut community - Reading through G-shut draft, it seems to be targeting = a=20 single use case - maintenance. Additionally, it requires manual=20 configuration of route-policies. The way I envision this is a simple Update= that is applicable to all peers; no need to worry about manipulating any B= GP attributes.

re: new SAFI - The reason for reques= ting a new SAFI is so that a new NLRI encoding can be defined to keep it si= mple. The existing SAFI would require adding NLRIs to the Update message.

re: BGP session distinction - Is there a need to identify = IBGP or EBGP session? Perhaps I am missing something.

re:= Global mode - the use case would be if a BGP speaker has multiple links to= different peers and running different AFI/SAFI pairs per links, it might b= e just easy to drain a particular type of traffic rather than ALL traffic. =

Additionally, one of the other use cases I am= thinking of is when a BGP speaker drops=20 its Established neighbor-count below a threshold, it can advertise=20 itself as "Overloaded". This can help avoid congestion. Agreed, t= his can also be the cause of network outage, but within a CLOS fabric, it=20 should not be a problem due to multiple paths.

Again, thanks for reviewing.

Amit.

On Tue, Jul 5, 2016 at = 12:39 PM, Robert Raszuk <robert@raszuk.net> wrote:

Hi Amit,

In an essence it seems that= your proposal is just a subset of "Graceful BGP session shutdown"= ;=C2=A0https://tools.ietf.org/ht= ml/draft-ietf-grow-bgp-gshut-06.=C2=A0

Can you clarify how your encoding is any better then p= roposed by Pierre's, et al. G-Shut community?=C2=A0

Why do you need a new SAFI for it ? Would= it be easier to use community or attribute and send it over existing SAFIs= ?=C2=A0

How in your e= ncoding one can distinguish IBGP sessions from EBGP sessions (case of core = or edge line card replacement) ?=C2=A0

What is the use case to not use "global" mode ..= ie. when do you envision need to signal overload for only subset of AFI/SA= FIs carried by given BGP speaker ?

Many Thx,
Robert.

On Tue, Jul 5, 2016 at 9:25 PM, amit bhagat <<= a href=3D"mailto:scet.amit@gmail.com" target=3D"_blank">scet.amit@gmail.com= > wrote:

<= div class=3D"h5">
Hey All,

We are looking for your comments on the new draft https://datatracker.ietf.org/doc/draft-bhagat-bgp-overload/

We would really ap= preciate any comments and questions about the document. =20 Best Regards,
Amit Bhagat

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

--001a11c10850da391e0536eac0c7-- From nobody Tue Jul 5 15:36:52 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 A421612D0FD for ; Tue, 5 Jul 2016 15:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, 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 dchM7IXx1WkG for ; Tue, 5 Jul 2016 15:36:47 -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 474AE12B022 for ; Tue, 5 Jul 2016 15:36:47 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id l188so143787716lfe.2 for ; Tue, 05 Jul 2016 15:36: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=G8KYTAWYRKVHksgDs07ObZ/8OdqoH2nP2FmfezUI8LU=; b=QhxDiig/VEKUEHl8spb/lMrkulfPPsSwYK791wK7gNZOgI4hOVOz33WxMWefrrkofH 0JjXnpXIMoQZfpt2qCw3LqwTjvYVoAdGaFuua3NZhu5GQ3npRgTIxKBoRUhLWWSVwr2E UOisXLxj6mSXjSqSIbMvaGy9JCqLQ4Z1WJxGyd15CRoDFhVwwmn3It71dRiYprKz1ZsO CppYNHpeEeRCXPjiXlZ6RSnZhZQHcnPWfrUJdKNthaJkiwl3lmMn/u3xlzUpu3x48yXN RFkUxeYTniIZYvb2EC+c8FowGxqDiUmYApOer28RlF6uOwlH+9I4W5Fbjhq65Yl41KR4 u1mA== 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=G8KYTAWYRKVHksgDs07ObZ/8OdqoH2nP2FmfezUI8LU=; b=eU4wbm/SP/D34+U3D4K3EVXbPWJOtXhEDwlt3I0ogQ3DLUIsfMLttnMilX80cufW5W xU8VfA0YKmc0ocjVtKHUeWGvgT74fhjkBXDJ59bvUJKLToYr/CQKsaOYvEMvKSOdTevl sjBstSUTKH4ZesMH8j0YtFndyiFhZ/Jt4MR/LGd6QZMSBUFpAaP4N2hG/Cqc/B6ooJ3/ xq4/7DwfPXARWY+Fe1qb3515aHHvMKI2nQji6vu7R6kOU9LicILug54RPRqQSOyZjsW/ IwqnHhfjUSuB2ffuYxGSYCroLN5m1E1WiY88IWSh/utf4lPtRrExY0VJHAdsJlAtZTzB nKlQ== X-Gm-Message-State: ALyK8tJSr9RPIFUgDHEXuaJjmk9bwiyaUlkZz0atUPOl3vM0h1sDFbJL1774S747OeQJxjTfWmrMShfoT0zwhA== X-Received: by 10.25.18.35 with SMTP id h35mr4118387lfi.82.1467758205139; Tue, 05 Jul 2016 15:36:45 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Tue, 5 Jul 2016 15:36:44 -0700 (PDT) In-Reply-To: References:

From: Robert Raszuk Date: Wed, 6 Jul 2016 00:36:44 +0200 X-Google-Sender-Auth: XOU7ZRx2RCJxgJz6wSh0Y1yHVuM Message-ID: To: amit bhagat Content-Type: multipart/alternative; boundary=001a113fbed26f00670536eb168e Archived-At: Cc: idr wg Subject: Re: [Idr] Review Request for draft BGP Overload 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, 05 Jul 2016 22:36:50 -0000 --001a113fbed26f00670536eb168e Content-Type: text/plain; charset=UTF-8 Hi Amit, Thank you for follow-up. One thing which perhaps needs to be addressed is how this (and few other recent proposals) is relates to Internet BGP vs L3 Clos DC fabric BGP. If your problem description is limited just to the latter due to inherent ECMP such message needs to only go one hop - so even a simple ORF extension will do just fine. Few years back BGP was stretched in one direction to accommodate carrying VPN information in WANs. Now I see it being more and more stretched in the opposite direction to accommodate various use case for DC underlay routing. And I think we all can realize what happens when you take even best material and stretch it with sufficient force in opposite directions :). As far as this draft to me what would be the best envelope for the information is really a new BGP message type .. BGP Operational Message. The work on that started few years back but were a bit put on hold. Defining new SAFI and making spagetti of SAFI-X to SAFI-Y operational inter-dependency kills the ability to separate SAFI dependent code from AF generic processing. Now if your use case is just about Clos topology in a given DC why not to use MED or LocalPref depending if your fabric is eBGP or iBGP based ? Is really re-advertisement of underlay routes such an issue ? Best regards, R. On Wed, Jul 6, 2016 at 12:12 AM, amit bhagat wrote: > Hi Robert, > > Many thanks for your comments. > > Initially, I thought about using a community but that would mean putting > all NLRIs in the Update message. This could also mean a different Update > per-neighbor/per-peergroup. > > re: G-shut community - Reading through G-shut draft, it seems to be > targeting a single use case - maintenance. Additionally, it requires manual > configuration of route-policies. The way I envision this is a simple Update > that is applicable to all peers; no need to worry about manipulating any > BGP attributes. > > re: new SAFI - The reason for requesting a new SAFI is so that a new NLRI > encoding can be defined to keep it simple. The existing SAFI would require > adding NLRIs to the Update message. > > re: BGP session distinction - Is there a need to identify IBGP or EBGP > session? Perhaps I am missing something. > > re: Global mode - the use case would be if a BGP speaker has multiple > links to different peers and running different AFI/SAFI pairs per links, it > might be just easy to drain a particular type of traffic rather than ALL > traffic. > > Additionally, one of the other use cases I am thinking of is when a BGP > speaker drops its Established neighbor-count below a threshold, it can > advertise itself as "Overloaded". This can help avoid congestion. Agreed, > this can also be the cause of network outage, but within a CLOS fabric, it > should not be a problem due to multiple paths. > > Again, thanks for reviewing. > > Amit. > > On Tue, Jul 5, 2016 at 12:39 PM, Robert Raszuk wrote: > >> Hi Amit, >> >> In an essence it seems that your proposal is just a subset of "Graceful >> BGP session shutdown" >> https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06. >> >> Can you clarify how your encoding is any better then proposed by >> Pierre's, et al. G-Shut community? >> >> Why do you need a new SAFI for it ? Would it be easier to use community >> or attribute and send it over existing SAFIs ? >> >> How in your encoding one can distinguish IBGP sessions from EBGP sessions >> (case of core or edge line card replacement) ? >> >> What is the use case to not use "global" mode .. ie. when do you envision >> need to signal overload for only subset of AFI/SAFIs carried by given BGP >> speaker ? >> >> Many Thx, >> Robert. >> >> >> On Tue, Jul 5, 2016 at 9:25 PM, amit bhagat wrote: >> >>> Hey All, >>> >>> We are looking for your comments on the new draft >>> https://datatracker.ietf.org/doc/draft-bhagat-bgp-overload/ >>> >>> We would really appreciate any comments and questions about the document. >>> >>> Best Regards, >>> >>> Amit Bhagat >>> >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >>> >> > --001a113fbed26f00670536eb168e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Amit,

Thank you for follow-up.=C2=A0

One thing which perhaps needs to be address= ed is how this (and few other recent proposals) is relates to Internet BGP = vs L3 Clos DC fabric BGP. If your problem description is limited just to th= e latter due to inherent ECMP such message needs to only go one hop - so ev= en a simple ORF extension will do just fine.=C2=A0

Few years back BGP was stretched in one direct= ion to accommodate carrying VPN information in WANs. Now I see it being mor= e and more stretched in the opposite direction to accommodate various use c= ase for DC underlay routing.=C2=A0

And I think we all can realize what happens when you take eve= n best material and stretch it with sufficient force in opposite directions= :).=C2=A0

As far as t= his draft to me what would be the best envelope for the information is real= ly a new BGP message type .. BGP Operational Message. The work on that star= ted few years back but were a bit put on hold.=C2=A0

Defining new SAFI and making spagetti of SAF= I-X to SAFI-Y operational inter-dependency kills the ability to separate SA= FI dependent code from AF generic processing.=C2=A0

Now if your use case is just about Clos topol= ogy in a given DC why not to use MED or LocalPref depending if your fabric = is eBGP or iBGP based ? Is really re-advertisement of underlay routes such = an issue ?=C2=A0

Best = regards,

=C2=A0

On Wed, Jul 6, 2016 at 12:12 AM, amit bhagat <scet.amit@gmail.com> wrote:

Hi Robert,

Many th= anks for your comments.

Initially, I thought about using a com= munity but that would mean putting all NLRIs in the Update message. This co= uld also mean a different Update per-neighbor/per-peergroup.

r= e: G-shut community - Reading through G-shut draft, it seems to be targetin= g a=20 single use case - maintenance. Additionally, it requires manual=20 configuration of route-policies. The way I envision this is a simple Update= that is applicable to all peers; no need to worry about manipulating any B= GP attributes.

re: new SAFI - The reason for reques= ting a new SAFI is so that a new NLRI encoding can be defined to keep it si= mple. The existing SAFI would require adding NLRIs to the Update message.
re: BGP session distinction - Is there a need to identify = IBGP or EBGP session? Perhaps I am missing something.

re:= Global mode - the use case would be if a BGP speaker has multiple links to= different peers and running different AFI/SAFI pairs per links, it might b= e just easy to drain a particular type of traffic rather than ALL traffic. =

Additionally, one of the other use cases I am= thinking of is when a BGP speaker drops=20 its Established neighbor-count below a threshold, it can advertise=20 itself as "Overloaded". This can help avoid congestion. Agreed, t= his can also be the cause of network outage, but within a CLOS fabric, it=20 should not be a problem due to multiple paths.

Again, thanks for reviewing.

Amit.

On Tue, J= ul 5, 2016 at 12:39 PM, Robert Raszuk <robert@raszuk.net> wr= ote:

= Hi Amit,

In an essence= it seems that your proposal is just a subset of "Graceful BGP session= shutdown"=C2=A0https://too= ls.ietf.org/html/draft-ietf-grow-bgp-gshut-06.=C2=A0

Can you clarify how your encoding is any= better then proposed by Pierre's, et al. G-Shut community?=C2=A0
=

Why do you need a new SAFI = for it ? Would it be easier to use community or attribute and send it over = existing SAFIs ?=C2=A0

How in your encoding one can distinguish IBGP sessions from EBGP sessions = (case of core or edge line card replacement) ?=C2=A0

What is the use case to not use "global= " mode .. ie. when do you envision need to signal overload for only su= bset of AFI/SAFIs carried by given BGP speaker ?
Many Thx,
Robert.
On Tue, Jul 5, 2016 at 9:25 PM, amit bhagat <scet.amit@gmail.com> wrote:
Hey = All,

We = are looking for your comments on the new draft https://datat= racker.ietf.org/doc/draft-bhagat-bgp-overload/
We would really appreciate any co=
mments and questions about the document.
=20
Best Regards,
Amit Bhagat
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--001a113fbed26f00670536eb168e-- From nobody Tue Jul 5 16:08:11 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 D8CC912D115 for ; Tue, 5 Jul 2016 16:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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 D3bTLFkORt5b for ; Tue, 5 Jul 2016 16:08:07 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 2A26B12B02F for ; Tue, 5 Jul 2016 16:08:07 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id s126so17893125qkh.2 for ; Tue, 05 Jul 2016 16:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L8MTHQeuxV9mqIhKBA1+UJjz60fBS6bRh3GDiVoEj6E=; b=RMRhyuTNPtZ+FEA/RmVDatUZQbuMZZQpHugsg2UYOIrkMcdWYsGluPc7UYcL8Q9ejD 3sWkeN+zOvNpJqUaJHcV+zLb0a96h2+68HTTSD85NOklZVDtPslPCXe/0OAxd6iGyxaX 6URTzlQbcCDherS6ZvmXdpGuEcMcbzoiT9sCxE4IDAIPoB5LjXfn+SbqWpFZrGfq8piG AHek7ARdQ/F/3NQvbbimzeBQmPeDCDVlu1AiNxkjraPu68HLWQ/oCYRjPsX5IDIHbQzA dBCsk5Lcp/0Cr7OVtMFB9gwiYviIc/EYH5v8I53P5SuskgkXoodvxTdRUNesT0mv6iKq W4bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L8MTHQeuxV9mqIhKBA1+UJjz60fBS6bRh3GDiVoEj6E=; b=iDdP4s+CGwAupS70AfNjGMzFpZ9sjgOFaU41d+B6pBqlm3n+jqeMqAcd5J3iZU2WIW PIf1Lp2TMsxonWrLqrZEoWiPGWnq0IjDwkQFbUjG7GvcCnOCk7/vft/IMaDxaM2cki2i IXGWmc8TPraMOjzleo8bFXkEEAuX+ZZvsD2CTJRYoE+QAuV3ff16No57sD6SYQd4NdbE vqPHh0oydoYkS3RGrbAumITukiV1sKpvRzu7DAFRIFJkgHSaqJZp7yBtrHNXhPxaiLKw R5j4fRWmqAJBcTMKCZ28f24Y9Zj5yvpXyJghpVTUXiGh08mg/EFRTq7DMVKMbmckPTs4 rv3Q== X-Gm-Message-State: ALyK8tLppkcqE5xBcd1w4skAY4pau2tlqRQMbVxJAbNfCLcYquJyg8p579iZ1mq7OCghzsEg9z+olZaEMgh4ig== X-Received: by 10.55.188.198 with SMTP id m189mr25514605qkf.205.1467760086357; Tue, 05 Jul 2016 16:08:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.43.232 with HTTP; Tue, 5 Jul 2016 16:08:05 -0700 (PDT) In-Reply-To: References:

From: amit bhagat Date: Tue, 5 Jul 2016 16:08:05 -0700 Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary=94eb2c048d24901dd40536eb86c8 Archived-At: Cc: idr wg Subject: Re: [Idr] Review Request for draft BGP Overload 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, 05 Jul 2016 23:08:10 -0000 --94eb2c048d24901dd40536eb86c8 Content-Type: text/plain; charset=UTF-8 Hi Robert, I agree that recently BGP is being stretched towards DC-fabric side to encompass various use cases. However, the way I see this draft, it can be useful for both, Internet and DC-fabrics. The main reason is to keep traffic drain procedure BGP topology agnostic, exactly same as ISIS Overload-bit. Agree, BGP has a bigger blast radius in Internet compared to ISIS but appropriate implementation of the feature can provide good benefits. Thanks. Amit On Tue, Jul 5, 2016 at 3:36 PM, Robert Raszuk wrote: > Hi Amit, > > Thank you for follow-up. > > One thing which perhaps needs to be addressed is how this (and few other > recent proposals) is relates to Internet BGP vs L3 Clos DC fabric BGP. If > your problem description is limited just to the latter due to inherent ECMP > such message needs to only go one hop - so even a simple ORF extension will > do just fine. > > Few years back BGP was stretched in one direction to accommodate carrying > VPN information in WANs. Now I see it being more and more stretched in the > opposite direction to accommodate various use case for DC underlay routing. > > And I think we all can realize what happens when you take even best > material and stretch it with sufficient force in opposite directions :). > > As far as this draft to me what would be the best envelope for the > information is really a new BGP message type .. BGP Operational Message. > The work on that started few years back but were a bit put on hold. > > Defining new SAFI and making spagetti of SAFI-X to SAFI-Y operational > inter-dependency kills the ability to separate SAFI dependent code from AF > generic processing. > > Now if your use case is just about Clos topology in a given DC why not to > use MED or LocalPref depending if your fabric is eBGP or iBGP based ? Is > really re-advertisement of underlay routes such an issue ? > > Best regards, > R. > > > > > > > On Wed, Jul 6, 2016 at 12:12 AM, amit bhagat wrote: > >> Hi Robert, >> >> Many thanks for your comments. >> >> Initially, I thought about using a community but that would mean putting >> all NLRIs in the Update message. This could also mean a different Update >> per-neighbor/per-peergroup. >> >> re: G-shut community - Reading through G-shut draft, it seems to be >> targeting a single use case - maintenance. Additionally, it requires manual >> configuration of route-policies. The way I envision this is a simple Update >> that is applicable to all peers; no need to worry about manipulating any >> BGP attributes. >> >> re: new SAFI - The reason for requesting a new SAFI is so that a new NLRI >> encoding can be defined to keep it simple. The existing SAFI would require >> adding NLRIs to the Update message. >> >> re: BGP session distinction - Is there a need to identify IBGP or EBGP >> session? Perhaps I am missing something. >> >> re: Global mode - the use case would be if a BGP speaker has multiple >> links to different peers and running different AFI/SAFI pairs per links, it >> might be just easy to drain a particular type of traffic rather than ALL >> traffic. >> >> Additionally, one of the other use cases I am thinking of is when a BGP >> speaker drops its Established neighbor-count below a threshold, it can >> advertise itself as "Overloaded". This can help avoid congestion. Agreed, >> this can also be the cause of network outage, but within a CLOS fabric, it >> should not be a problem due to multiple paths. >> >> Again, thanks for reviewing. >> >> Amit. >> >> On Tue, Jul 5, 2016 at 12:39 PM, Robert Raszuk wrote: >> >>> Hi Amit, >>> >>> In an essence it seems that your proposal is just a subset of "Graceful >>> BGP session shutdown" >>> https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06. >>> >>> Can you clarify how your encoding is any better then proposed by >>> Pierre's, et al. G-Shut community? >>> >>> Why do you need a new SAFI for it ? Would it be easier to use community >>> or attribute and send it over existing SAFIs ? >>> >>> How in your encoding one can distinguish IBGP sessions from EBGP >>> sessions (case of core or edge line card replacement) ? >>> >>> What is the use case to not use "global" mode .. ie. when do you >>> envision need to signal overload for only subset of AFI/SAFIs carried by >>> given BGP speaker ? >>> >>> Many Thx, >>> Robert. >>> >>> >>> On Tue, Jul 5, 2016 at 9:25 PM, amit bhagat wrote: >>> >>>> Hey All, >>>> >>>> We are looking for your comments on the new draft >>>> https://datatracker.ietf.org/doc/draft-bhagat-bgp-overload/ >>>> >>>> We would really appreciate any comments and questions about the document. >>>> >>>> Best Regards, >>>> >>>> Amit Bhagat >>>> >>>> >>>> >>>> _______________________________________________ >>>> Idr mailing list >>>> Idr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/idr >>>> >>>> >>> >> > --94eb2c048d24901dd40536eb86c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Robert,

I agree that r= ecently BGP is being stretched towards DC-fabric side to encompass various = use cases.

However, the way I see this draft, it can be useful= for both, Internet and DC-fabrics. The main reason is to keep traffic drai= n procedure BGP topology agnostic, exactly same as ISIS Overload-bit. Agree= , BGP has a bigger blast radius in Internet compared to ISIS but appropriat= e implementation of the feature can provide good benefits.

Tha= nks.

Amit

On Tue, Jul 5, 2016 at 3:36 PM, Robert Raszuk = <robert@raszuk.ne= t> wrote:

=
Hi Amit,

Thank you for follow-up.=C2=A0

One thing which perhaps needs to be addressed is how this (a= nd few other recent proposals) is relates to Internet BGP vs L3 Clos DC fab= ric BGP. If your problem description is limited just to the latter due to i= nherent ECMP such message needs to only go one hop - so even a simple ORF e= xtension will do just fine.=C2=A0

Few years back BGP was stretched in one direction to accommod= ate carrying VPN information in WANs. Now I see it being more and more stre= tched in the opposite direction to accommodate various use case for DC unde= rlay routing.=C2=A0

An= d I think we all can realize what happens when you take even best material = and stretch it with sufficient force in opposite directions :).=C2=A0
=

As far as this draft to me = what would be the best envelope for the information is really a new BGP mes= sage type .. BGP Operational Message. The work on that started few years ba= ck but were a bit put on hold.=C2=A0

Defining new SAFI and making spagetti of SAFI-X to SAFI-Y op= erational inter-dependency kills the ability to separate SAFI dependent cod= e from AF generic processing.=C2=A0

Now if your use case is just about Clos topology in a given D= C why not to use MED or LocalPref depending if your fabric is eBGP or iBGP = based ? Is really re-advertisement of underlay routes such an issue ?=C2=A0=

Best regards,

=C2=A0

On Wed, Jul 6, 2016 at 1= 2:12 AM, amit bhagat <scet.amit@gmail.com> wrote:

Hi Robe= rt,

Many thanks for your comments.

Initially, I t= hought about using a community but that would mean putting all NLRIs in the= Update message. This could also mean a different Update per-neighbor/per-p= eergroup.

re: G-shut community - Reading through G-shut draft,= it seems to be targeting a=20 single use case - maintenance. Additionally, it requires manual=20 configuration of route-policies. The way I envision this is a simple Update= that is applicable to all peers; no need to worry about manipulating any B= GP attributes.

re: new SAFI - The reason for reques= ting a new SAFI is so that a new NLRI encoding can be defined to keep it si= mple. The existing SAFI would require adding NLRIs to the Update message.

re: BGP session distinction - Is there a need to identify = IBGP or EBGP session? Perhaps I am missing something.

Again, thanks for reviewing.

<= /span>

Amit.

= On Tue, Jul 5, 2016 at 12:39 PM, Robert Raszuk <robert@raszuk.net><= /span> wrote:

Hi Amit,

In a= n essence it seems that your proposal is just a subset of "Graceful BG= P session shutdown"=C2=A0ht= tps://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06.=C2=A0

Can you clarify how your encodi= ng is any better then proposed by Pierre's, et al. G-Shut community?=C2= =A0

Why do you need a = new SAFI for it ? Would it be easier to use community or attribute and send= it over existing SAFIs ?=C2=A0

How in your encoding one can distinguish IBGP sessions from EBGP = sessions (case of core or edge line card replacement) ?=C2=A0

What is the use case to not use &qu= ot;global" mode .. ie. when do you envision need to signal overload fo= r only subset of AFI/SAFIs carried by given BGP speaker ?

Many Thx,
Robert.

On Tue, Jul 5, 2016 at 9:25 PM, amit bhagat <scet.amit= @gmail.com> wrote:

Hey All,

We are looking for your comments on the new draft h= ttps://datatracker.ietf.org/doc/draft-bhagat-bgp-overload/

We would really appre= ciate any comments and questions about the document. =20 Best Regards,
Amit Bhagat
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

--94eb2c048d24901dd40536eb86c8-- From nobody Tue Jul 5 16:10:20 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 9556F12D15E for ; Tue, 5 Jul 2016 16:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 JYeZnoKI9q39 for ; Tue, 5 Jul 2016 16:10:16 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C113D12D158 for ; Tue, 5 Jul 2016 16:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1648; q=dns/txt; s=iport; t=1467760216; x=1468969816; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=L3R4POy15dPWPVkNNZxxk0EKd6vfOd/KsFnrrnwmB4U=; b=T6UsspAyaldff8vwfXdFe0xzSkYaHqXx0FhBb/bdeWeTX+zhdPjUuO74 Gx2MXssPnuTT45RAt4DkP5IBXlC9j/kzceoZbGYpZ1n65e2GCiy80bxIk Gdz+dbjNkNMOUrx6Nkl2RwKKVs2dXPh6yxHkXMtk+p9Ps+0hnPEBWn4BR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgD7PXxX/40NJK1cgz5WfAatMowQg?= =?us-ascii?q?XckhXQCHIEUOBQBAQEBAQEBZRwLhEwBAQUjEUMOBAIBCBoCJgICAh8RFQYBBgM?= =?us-ascii?q?CBBMIDIgCAxcOq2iLQA2EMQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQGFJoRNg?= =?us-ascii?q?kOEfoJaBY4EhVWFBjQBhgiGLoIJjzGIF4dyAR42g3BuAYdUAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.28,315,1464652800"; d="scan'208";a="293854662" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Jul 2016 23:10:16 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u65NAF0Z000483 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 5 Jul 2016 23:10:15 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 18:10:15 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 18:10:15 -0500 From: "Jakob Heitz (jheitz)" To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-heitz-idr-large-community-00.txt Thread-Index: AQHR1wxN7gRrWu0/MEuLSZwDv2jjd6AKbpHw Date: Tue, 5 Jul 2016 23:10:15 +0000 Message-ID: References: <20160705222638.22322.81874.idtracker@ietfa.amsl.com> In-Reply-To: <20160705222638.22322.81874.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.26] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Idr] FW: New Version Notification for draft-heitz-idr-large-community-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, 05 Jul 2016 23:10:18 -0000 QSBsYXJnZXIgZXh0ZW5kZWQgY29tbXVuaXR5IGlzIHByb3Bvc2VkLg0KVGhlIGludGVudCBpcyBu b3QgdG8gcHJvdmlkZSBhIGZsZXhpYmxlIGFuZCBwb3dlcmZ1bA0KY29udGFpbmVyIGZvciBpbmZv cm1hdGlvbiwgYnV0IHNpbXBseSBhbiBpbmNyZWFzZSBpbg0Kc2l6ZSB3aXRob3V0IGltcGFjdGlu ZyB0aGUgcm91dGluZyBwb2xpY2llcyB0aGF0IG9wZXJhdG9ycw0KY3VycmVudGx5IHVzZS4NCg0K Q29tbWVudHMgYXJlIHdlbGNvbWUuDQoNClRoYW5rcywNCkpha29iIEhlaXR6LA0KSm9iIFNuaWpk ZXJzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KVG86IEpha29iIEhlaXR6IChqaGVp dHopIDxqaGVpdHpAY2lzY28uY29tPjsgSWduYXMgQmFnZG9uYXMgPGliYWdkb25hLmlldGZAZ21h aWwuY29tPjsgSm9iIFNuaWpkZXJzIDxqb2JAbnR0Lm5ldD47IEtleXVyIFBhdGVsIChrZXl1cGF0 ZSkgPGtleXVwYXRlQGNpc2NvLmNvbT4NCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt aGVpdHotaWRyLWxhcmdlLWNvbW11bml0eS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgSmFrb2IgSGVpdHogYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZToJCWRyYWZ0LWhlaXR6LWlkci1sYXJnZS1jb21tdW5pdHkNClJldmlzaW9uOgkw MA0KVGl0bGU6CQlMYXJnZSBCR1AgQ29tbXVuaXR5DQpEb2N1bWVudCBkYXRlOgkyMDE2LTA3LTA1 DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk5DQpVUkw6ICAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhlaXR6LWlkci1s YXJnZS1jb21tdW5pdHktMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaGVpdHotaWRyLWxhcmdlLWNvbW11bml0eS8NCkh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGVpdHotaWRyLWxhcmdl LWNvbW11bml0eS0wMA0KDQoNCkFic3RyYWN0Og0KICAgQSBuZXcgdHlwZSBvZiBCR1AgY29tbXVu aXR5IGF0dHJpYnV0ZSB0aGF0IGNvbnRhaW5zIGNvbW11bml0aWVzIHRoYXQNCiAgIGVhY2ggaG9s ZCBhIDQtb2N0ZXQgQVMgbnVtYmVyIGFuZCBhIDYtb2N0ZXQgb3BhcXVlIGZpZWxkIGlzIGRlZmlu ZWQuDQo= From nobody Tue Jul 5 16:28:02 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 586A312D137 for ; Tue, 5 Jul 2016 16:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.638 X-Spam-Level: *** X-Spam-Status: No, score=3.638 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 JRrSdQttu1p3 for ; Tue, 5 Jul 2016 16:27:54 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 C758B12D520 for ; Tue, 5 Jul 2016 16:27:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.200; From: "Susan Hares" To: , "'Keyur Patel $keyupate$'" , , "'Bruno Decraene'" , "'Henderickx, Wim $Nokia - BE$'" , Date: Tue, 5 Jul 2016 19:27:12 -0400 Message-ID: <068e01d1d714$c3002760$49007620$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_068F_01D1D6F3.3BEEFC90" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdHXFCd9QgWs5X1ZTnmBFEDm50qIHg== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) 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, 05 Jul 2016 23:27:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_068F_01D1D6F3.3BEEFC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This ends the 2 week WG Adoption call for draft-keyupate-idr-bgp-attribute-announcement. The WG has adopted this draft. The Co-chairs forgot to do an IPR call on this draft. The authors should indicate whether they know of IPR on this draft. After we receive all the IPR statements, the authors will be able to upload this as draft-ietf-idr-bgp-attribute-announcement-00.txt. Sue Hares and John Scudder. ------=_NextPart_000_068F_01D1D6F3.3BEEFC90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This ends the 2 week WG Adoption call for = draft-keyupate-idr-bgp-attribute-announcement. The WG has adopted = this draft.

The Co-chairs forgot to do an IPR call on this = draft. The authors should indicate whether they know of IPR = on this draft. After we receive all the IPR statements, the = authors will be able to upload this as = draft-ietf-idr-bgp-attribute-announcement-00.txt. =

Sue Hares and John Scudder. =

------=_NextPart_000_068F_01D1D6F3.3BEEFC90-- From nobody Tue Jul 5 17: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 4984712D0CA for ; Tue, 5 Jul 2016 17:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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.426, 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 PeVOlVtdO0RK for ; Tue, 5 Jul 2016 17:05:41 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE62D12D1AF for ; Tue, 5 Jul 2016 17:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6196; q=dns/txt; s=iport; t=1467763538; x=1468973138; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BwO88np8Ne8BWEdb8qGQnzl2k4J7kneJXVtjzEWdqQM=; b=dwasXEpq3qswVTRr/y9TkVHQKHb/J35O++zceMDQIHS6Ul61gf5Emgws 3WjwnR/xTPCA5RHkaaKX+L7OrToC4DUe3lkgYP5MGWXreSAgLL1PpxERW sksEDLTWK3PHKKjdJCprDFyjwRyOODag7ziAGWD/SVvhCgcL49/bQOlJJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAgClSnxX/5ldJa1cgnBOVnwGtEOFA?= =?us-ascii?q?YF3hhgCgTA4FAEBAQEBAQFlJ4RMAQEFHRBMEAIBCA4DAwECJAQHMhQJCAIEAQ0?= =?us-ascii?q?FiDC7fAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4RNhGCFOwWTWYU6AY5GjyqQC?= =?us-ascii?q?QEeNoI7gTVuh1V/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,316,1464652800"; d="scan'208,217";a="294051608" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 00:05:37 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6605bSu018462 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jul 2016 00:05:37 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 20:05:36 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 20:05:36 -0400 From: "Keyur Patel (keyupate)" To: Susan Hares , "idr@ietf.org" , "uttaro@att.com" , "'Bruno Decraene'" , "'Henderickx, Wim (Nokia - BE)'" , "jhaas@pfrc.org" Thread-Topic: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) Thread-Index: AQHR1xofQA6BrIY5ZEmYcC2sVJZtqw== Date: Wed, 6 Jul 2016 00:05:36 +0000 Message-ID: References: <068e01d1d714$c3002760$49007620$@ndzh.com> In-Reply-To: <068e01d1d714$c3002760$49007620$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.162.162] Content-Type: multipart/alternative; boundary="_000_D3A1993345D98keyupateciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) 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, 06 Jul 2016 00:05:44 -0000 --_000_D3A1993345D98keyupateciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR related to this document. Regards, Keyur From: Susan Hares > Date: Wednesday, July 6, 2016 at 1:27 AM To: "idr@ietf.org" >= , Keyur Patel >, "uttaro@att.= com" >, 'Bruno= Decraene' >, "= 'Henderickx, Wim (Nokia - BE)'" >, "jhaas@pfrc.org" > Cc: "'John G. Scudder'" > Subject: RE: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announce= ment - 2 week WG Adoption call (6/6 to 6/20) This ends the 2 week WG Adoption call for draft-keyupate-idr-bgp-attribute-= announcement. The WG has adopted this draft. The Co-chairs forgot to do an IPR call on this draft. The authors should = indicate whether they know of IPR on this draft. After we receive all the= IPR statements, the authors will be able to upload this as draft-ietf-idr-= bgp-attribute-announcement-00.txt. Sue Hares and John Scudder. --_000_D3A1993345D98keyupateciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR related to this document.

Regards,

Keyur

From: Susan Hares <shares@ndzh.com>
Date: Wednesday, July 6, 2016 at 1:= 27 AM
To: "idr@ietf.org" <idr@ietf.= org>, Keyur Patel <keyupate= @cisco.com>, "uttaro@att.com<= /a>" <uttaro@att.com>, 'Bruno Decra= ene' <bruno.decraene@orange= .com>, "'Henderickx, Wim (Nokia - BE)'" <wim.henderickx@nokia.com>, "jhaas@pfrc.org" <jhaas@pfrc.org>
Cc: "'John G. Scudder'" &= lt;jgs@juniper.net>
Subject: RE: [Idr] WG Adoption of d= raft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6= to 6/20)

This ends the 2 week WG Adoption call = for draft-keyupate-idr-bgp-attribute-announcement. The WG has adopted= this draft.

The Co-chairs forgot to do an IPR call= on this draft. The authors should indicate whether they know o= f IPR on this draft. After we receive all the IPR statements, the authors will be able to upload this as draft-ietf-idr-= bgp-attribute-announcement-00.txt.

Sue Hares and John Scudder.

--_000_D3A1993345D98keyupateciscocom_-- From nobody Tue Jul 5 23:18: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 393D512B05C for ; Tue, 5 Jul 2016 23:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 LEyz_ygICCHG for ; Tue, 5 Jul 2016 23:18:30 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 37AEB12B03D for ; Tue, 5 Jul 2016 23:18:30 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 57832C9B2E0A3; Wed, 6 Jul 2016 06:18:25 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u666IPrU001207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2016 06:18:26 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u666IOaY002705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Jul 2016 08:18:25 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.160]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 6 Jul 2016 08:18:24 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "Keyur Patel (keyupate)" , Susan Hares , "idr@ietf.org" , "uttaro@att.com" , "'Bruno Decraene'" , "jhaas@pfrc.org" Thread-Topic: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) Thread-Index: AQHR1xouBGjuO1kQsE2xQtFsweKRXqAK7jGA Date: Wed, 6 Jul 2016 06:18:23 +0000 Message-ID: <6A4039E1-71DE-440A-B5E8-9EEF0A0448E7@alcatel-lucent.com> References: <068e01d1d714$c3002760$49007620$@ndzh.com> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_6A4039E171DE440AB5E89EEF0A0448E7alcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) 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, 06 Jul 2016 06:18:33 -0000 --_000_6A4039E171DE440AB5E89EEF0A0448E7alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBOb3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZG9jDQoNCkZyb206IEtl eXVyIFBhdGVsIDxrZXl1cGF0ZUBjaXNjby5jb208bWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbT4+ DQpEYXRlOiBXZWRuZXNkYXkgNiBKdWx5IDIwMTYgYXQgMDI6MDUNClRvOiBTdXNhbiBIYXJlcyA8 c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+PiwgImlkckBpZXRmLm9yZzxt YWlsdG86aWRyQGlldGYub3JnPiIgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4s IEppbSBVdHRhcm8gPHV0dGFyb0BhdHQuY29tPG1haWx0bzp1dHRhcm9AYXR0LmNvbT4+LCBCcnVu byBEZWNyYWVuZSA8YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFl bmVAb3JhbmdlLmNvbT4+LCBXaW0gSGVuZGVyaWNreCA8d2ltLmhlbmRlcmlja3hAbm9raWEuY29t PG1haWx0bzp3aW0uaGVuZGVyaWNreEBub2tpYS5jb20+PiwgImpoYWFzQHBmcmMub3JnPG1haWx0 bzpqaGFhc0BwZnJjLm9yZz4iIDxqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5vcmc+ Pg0KQ2M6ICInSm9obiBHLiBTY3VkZGVyJyIgPGpnc0BqdW5pcGVyLm5ldDxtYWlsdG86amdzQGp1 bmlwZXIubmV0Pj4NClN1YmplY3Q6IFJlOiBbSWRyXSBXRyBBZG9wdGlvbiBvZiBkcmFmdC1rZXl1 cGF0ZS1pZHItYmdwLWF0dHJpYnV0ZS1hbm5vdW5jZW1lbnQgLSAyIHdlZWsgV0cgQWRvcHRpb24g Y2FsbCAoNi82IHRvIDYvMjApDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0 byB0aGlzIGRvY3VtZW50Lg0KDQpSZWdhcmRzLA0KS2V5dXINCg0KRnJvbTogU3VzYW4gSGFyZXMg PHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NCkRhdGU6IFdlZG5lc2Rh eSwgSnVseSA2LCAyMDE2IGF0IDE6MjcgQU0NClRvOiAiaWRyQGlldGYub3JnPG1haWx0bzppZHJA aWV0Zi5vcmc+IiA8aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+PiwgS2V5dXIgUGF0 ZWwgPGtleXVwYXRlQGNpc2NvLmNvbTxtYWlsdG86a2V5dXBhdGVAY2lzY28uY29tPj4sICJ1dHRh cm9AYXR0LmNvbTxtYWlsdG86dXR0YXJvQGF0dC5jb20+IiA8dXR0YXJvQGF0dC5jb208bWFpbHRv OnV0dGFyb0BhdHQuY29tPj4sICdCcnVubyBEZWNyYWVuZScgPGJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+PiwgIidIZW5kZXJpY2t4LCBX aW0gKE5va2lhIC0gQkUpJyIgPHdpbS5oZW5kZXJpY2t4QG5va2lhLmNvbTxtYWlsdG86d2ltLmhl bmRlcmlja3hAbm9raWEuY29tPj4sICJqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5v cmc+IiA8amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpoYWFzQHBmcmMub3JnPj4NCkNjOiAiJ0pvaG4g Ry4gU2N1ZGRlciciIDxqZ3NAanVuaXBlci5uZXQ8bWFpbHRvOmpnc0BqdW5pcGVyLm5ldD4+DQpT dWJqZWN0OiBSRTogW0lkcl0gV0cgQWRvcHRpb24gb2YgZHJhZnQta2V5dXBhdGUtaWRyLWJncC1h dHRyaWJ1dGUtYW5ub3VuY2VtZW50IC0gMiB3ZWVrIFdHIEFkb3B0aW9uIGNhbGwgKDYvNiB0byA2 LzIwKQ0KDQpUaGlzIGVuZHMgdGhlIDIgd2VlayBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1r ZXl1cGF0ZS1pZHItYmdwLWF0dHJpYnV0ZS1hbm5vdW5jZW1lbnQuICBUaGUgV0cgaGFzIGFkb3B0 ZWQgdGhpcyBkcmFmdC4NClRoZSBDby1jaGFpcnMgZm9yZ290IHRvIGRvIGFuIElQUiBjYWxsIG9u IHRoaXMgZHJhZnQuICAgVGhlIGF1dGhvcnMgc2hvdWxkIGluZGljYXRlIHdoZXRoZXIgdGhleSBr bm93IG9mIElQUiBvbiB0aGlzIGRyYWZ0LiAgIEFmdGVyIHdlIHJlY2VpdmUgYWxsIHRoZSBJUFIg c3RhdGVtZW50cywgdGhlIGF1dGhvcnMgd2lsbCBiZSBhYmxlIHRvIHVwbG9hZCB0aGlzIGFzIGRy YWZ0LWlldGYtaWRyLWJncC1hdHRyaWJ1dGUtYW5ub3VuY2VtZW50LTAwLnR4dC4NClN1ZSBIYXJl cyBhbmQgSm9obiBTY3VkZGVyLg0K --_000_6A4039E171DE440AB5E89EEF0A0448E7alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <9F075CB85C20BD4A949A216A0AF21CAB@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkkgYW0gTm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRvYzwvZGl2Pg0K PGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0 OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9u ZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5H LUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBz b2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPktleXVyIFBhdGVsICZsdDs8 YSBocmVmPSJtYWlsdG86a2V5dXBhdGVAY2lzY28uY29tIj5rZXl1cGF0ZUBjaXNjby5jb208L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2Vk bmVzZGF5IDYgSnVseSAyMDE2IGF0IDAyOjA1PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlRvOiA8L3NwYW4+U3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNA bmR6aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86 aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0OywgSmltIFV0dGFybyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnV0dGFyb0BhdHQuY29tIj51dHRhcm9AYXR0LmNvbTwvYT4mZ3Q7LA0KIEJydW5v IERlY3JhZW5lICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+ YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7LCBXaW0gSGVuZGVyaWNreCAmbHQ7PGEg aHJlZj0ibWFpbHRvOndpbS5oZW5kZXJpY2t4QG5va2lhLmNvbSI+d2ltLmhlbmRlcmlja3hAbm9r aWEuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpqaGFhc0BwZnJjLm9yZyI+amhh YXNAcGZyYy5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmci PmpoYWFzQHBmcmMub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+Q2M6IDwvc3Bhbj4mcXVvdDsnSm9obiBHLiBTY3VkZGVyJyZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpnc0BqdW5pcGVyLm5ldCI+amdzQGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWRyXSBXRyBB ZG9wdGlvbiBvZiBkcmFmdC1rZXl1cGF0ZS1pZHItYmdwLWF0dHJpYnV0ZS1hbm5vdW5jZW1lbnQg LSAyIHdlZWsgV0cgQWRvcHRpb24gY2FsbCAoNi82IHRvIDYvMjApPGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIg cmVsYXRlZCB0byB0aGlzIGRvY3VtZW50LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ UmVnYXJkcyw8L2Rpdj4NCjxkaXY+S2V5dXI8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRF Ui1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkct Qk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRF Ui1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURE SU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3Nw YW4+U3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJl c0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRh dGU6IDwvc3Bhbj5XZWRuZXNkYXksIEp1bHkgNiwgMjAxNiBhdCAxOjI3IEFNPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRv OmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPiZndDssIEtleXVyIFBhdGVsICZsdDs8YSBo cmVmPSJtYWlsdG86a2V5dXBhdGVAY2lzY28uY29tIj5rZXl1cGF0ZUBjaXNjby5jb208L2E+Jmd0 OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnV0dGFyb0BhdHQuY29tIj51dHRhcm9AYXR0LmNvbTwv YT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnV0dGFyb0BhdHQuY29tIj51dHRhcm9AYXR0 LmNvbTwvYT4mZ3Q7LCAnQnJ1bm8gRGVjcmFlbmUnICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8u ZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7LCAm cXVvdDsnSGVuZGVyaWNreCwgV2ltIChOb2tpYSAtIEJFKScmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzp3aW0uaGVuZGVyaWNreEBub2tpYS5jb20iPndpbS5oZW5kZXJpY2t4QG5va2lhLmNvbTwv YT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciPmpoYWFzQHBmcmMu b3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciPmpoYWFz QHBmcmMub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6 IDwvc3Bhbj4mcXVvdDsnSm9obiBHLiBTY3VkZGVyJyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv Ompnc0BqdW5pcGVyLm5ldCI+amdzQGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJFOiBbSWRyXSBXRyBBZG9wdGlv biBvZiBkcmFmdC1rZXl1cGF0ZS1pZHItYmdwLWF0dHJpYnV0ZS1hbm5vdW5jZW1lbnQgLSAyIHdl ZWsgV0cgQWRvcHRpb24gY2FsbCAoNi82IHRvIDYvMjApDQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4 bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93 d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyog Rm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlRoaXMgZW5kcyB0aGUgMiB3ZWVrIFdHIEFkb3B0aW9uIGNhbGwgZm9y IGRyYWZ0LWtleXVwYXRlLWlkci1iZ3AtYXR0cmlidXRlLWFubm91bmNlbWVudC4mbmJzcDsgVGhl IFdHIGhhcyBhZG9wdGVkIHRoaXMgZHJhZnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIENv LWNoYWlycyBmb3Jnb3QgdG8gZG8gYW4gSVBSIGNhbGwgb24gdGhpcyBkcmFmdC4gJm5ic3A7Jm5i c3A7VGhlIGF1dGhvcnMgc2hvdWxkIGluZGljYXRlIHdoZXRoZXIgdGhleSBrbm93IG9mIElQUiBv biB0aGlzIGRyYWZ0LiAmbmJzcDsmbmJzcDtBZnRlciB3ZSByZWNlaXZlIGFsbCB0aGUNCiBJUFIg c3RhdGVtZW50cywgdGhlIGF1dGhvcnMgd2lsbCBiZSBhYmxlIHRvIHVwbG9hZCB0aGlzIGFzIGRy YWZ0LWlldGYtaWRyLWJncC1hdHRyaWJ1dGUtYW5ub3VuY2VtZW50LTAwLnR4dC4mbmJzcDsNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5TdWUgSGFyZXMgYW5kIEpvaG4gU2N1ZGRlci4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6A4039E171DE440AB5E89EEF0A0448E7alcatellucentcom_-- From nobody Wed Jul 6 00:17:41 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 7F1A812D692 for ; Wed, 6 Jul 2016 00:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 5p97gxdqFAbq for ; Wed, 6 Jul 2016 00:17:36 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FB512D68A for ; Wed, 6 Jul 2016 00:17:36 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 8EB65401DD; Wed, 6 Jul 2016 09:17:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 58B8D2010F; Wed, 6 Jul 2016 09:17:34 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0294.000; Wed, 6 Jul 2016 09:17:34 +0200 From: To: Susan Hares , "'John G. Scudder'" Thread-Topic: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) Thread-Index: AdHXFCd9QgWs5X1ZTnmBFEDm50qIHgAQi4hw Date: Wed, 6 Jul 2016 07:17:33 +0000 Message-ID: <12045_1467789454_577CB08E_12045_1818_1_53C29892C857584299CBF5D05346208A0F92D34C@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <068e01d1d714$c3002760$49007620$@ndzh.com> In-Reply-To: <068e01d1d714$c3002760$49007620$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F92D34COPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Cc: "'Keyur Patel $keyupate$'" , "idr@ietf.org" Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) 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, 06 Jul 2016 07:17:38 -0000 --_000_53C29892C857584299CBF5D05346208A0F92D34COPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, John, I'm not aware of IPR related to this draft. Regards, -- Bruno From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, July 06, 2016 1:27 AM To: idr@ietf.org; 'Keyur Patel (keyupate)'; uttaro@att.com; DECRAENE Bruno = IMT/OLN; 'Henderickx, Wim (Nokia - BE)'; jhaas@pfrc.org Cc: 'John G. Scudder' Subject: RE: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announce= ment - 2 week WG Adoption call (6/6 to 6/20) This ends the 2 week WG Adoption call for draft-keyupate-idr-bgp-attribute-= announcement. The WG has adopted this draft. The Co-chairs forgot to do an IPR call on this draft. The authors should = indicate whether they know of IPR on this draft. After we receive all the= IPR statements, the authors will be able to upload this as draft-ietf-idr-= bgp-attribute-announcement-00.txt. Sue Hares and John Scudder. ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F92D34COPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,= John,

&n= bsp;

I’= ;m not aware of IPR related to this draft.

&n= bsp;

Regards= ,

-- Brun= o

&n= bsp;

From: Susan Ha= res [mailto:shares@ndzh.com]
Sent: Wednesday, July 06, 2016 1:27 AM
To: idr@ietf.org; 'Keyur Patel (keyupate)'; uttaro@att.com; DECRAENE= Bruno IMT/OLN; 'Henderickx, Wim (Nokia - BE)'; jhaas@pfrc.org
Cc: 'John G. Scudder'
Subject: RE: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-a= nnouncement - 2 week WG Adoption call (6/6 to 6/20)

This ends the 2 week WG= Adoption call for draft-keyupate-idr-bgp-attribute-announcement. The= WG has adopted this draft.

The Co-chairs forgot to= do an IPR call on this draft. The authors should indicate whet= her they know of IPR on this draft. After we receive all the IPR statements, the authors will be able to upload this as draft-i= etf-idr-bgp-attribute-announcement-00.txt.

Sue Hares and John Scud= der.

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F92D34COPEXCLILM21corp_-- From nobody Wed Jul 6 00:35: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 B348412D6AE for ; Wed, 6 Jul 2016 00:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, 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 X_YsxXcllR1Q for ; Wed, 6 Jul 2016 00:34:57 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 0175A12D6A1 for ; Wed, 6 Jul 2016 00:34:56 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id f6so149074429lfg.0 for ; Wed, 06 Jul 2016 00:34:56 -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=aGNT42wL8LNBYDUF1abStR/WnTLa6MBlKsDAnHFGCT8=; b=RPR/P6XLP68qR39sQawm84EOcdwxtvWEc43uOPvtdAyJI//XDrBri4suE/OOGFUTEL KYLjY3nEw8IHbJpMMjYZWkZky4i2YJw2mXvUj9R+qh8llUcQxs+Dd4ogqxKfHvIZ2Hcl umNugQrtcz4osWtN0JBWlWs3XC+h0D+35VXzJkKH7dTsqbC21rRlSXLsMZSxeFF3Aij1 eeu1aTnCAIBVusT6Imq5f4LVpjDQJ7rzwitMzPga5oXlAv9ijYZ8UQg97DhzZM2s1LDH kS6mz+jqZreKpPKgr/WJiSeGCJoF1XR1NBZcIZg6VPlU1goJOLOyhpSX83fZu9oT5Yxm jOQA== 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=aGNT42wL8LNBYDUF1abStR/WnTLa6MBlKsDAnHFGCT8=; b=lnc7y/i6KGnVpjKR3wEACnWRvGYK3cEVqqe5wuDSFjKJAka6cjDdff9cV3GR73hBRV NY06repvp+BCvm3zmfL2Dubw7yYCfdMOTZ4L8pS0jjLGo9ktfMFgj6HC7SIyPoyYPRoD /l1XuFAgOgqGaGTtDqjMX5c0xYgovlpNPTRC2IPbdg+qvN+W+YTo+bht+4YNzHuwYFoN Bkg1dujB+Zh657qURdHaADqxdC8MEkhMKWPtfToWrZ9HC0WQ/5QLe0gtXUzB8wQ/fhPp 5kTi6x0khY4TzyDYUxzm2dfffvT0AsNtAwukzWxbbVRP5V959eWOknxASRScL0BewtmQ T+dA== X-Gm-Message-State: ALyK8tJiIA+IWm6LVEDOD2Nwjc7zMgWoCUe1LLyl9fmtctm5/nZ8qmqjbvAsgi/t0LFFVuJKSwV1S4MhODpqcQ== X-Received: by 10.25.18.35 with SMTP id h35mr4494316lfi.82.1467790494888; Wed, 06 Jul 2016 00:34:54 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Wed, 6 Jul 2016 00:34:54 -0700 (PDT) In-Reply-To: References:

From: Robert Raszuk Date: Wed, 6 Jul 2016 09:34:54 +0200 X-Google-Sender-Auth: rKutAckwRy2Risr48d3wYqYOL7o Message-ID: To: amit bhagat Content-Type: multipart/alternative; boundary=001a113fbed20d775e0536f29b78 Archived-At: Cc: idr wg Subject: Re: [Idr] Review Request for draft BGP Overload 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, 06 Jul 2016 07:35:00 -0000 --001a113fbed20d775e0536f29b78 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Amit, I agree that recently BGP is being stretched towards DC-fabric side to > encompass various use cases. > > However, the way I see this draft, it can be useful for both, Internet an= d > DC-fabrics. The main reason is to keep traffic drain procedure BGP topolo= gy > agnostic, exactly same as ISIS Overload-bit. Agree, BGP has a bigger blas= t > radius in Internet compared to ISIS but appropriate implementation of the > feature can provide good benefits. > =E2=80=8BI don't think =E2=80=8Bthis is about "blast radius". ISIS or OSPF = are link state protocols and each node in the given flooding scope computes its independent SPF hence flooding such information is a necessity for consistent forwarding. Contrary to the above BGP is path/distance-vector where each BGP speaker recomputes its bRIB and re-advertises it. Therefor for the use case you have in mind all what is required is to signal in some way to a bgp peer(s) that you may not want or want again to be in forwarding for a given SAFI. You defined a new SAFI as well as new NLRI format to use for point to point signalling .. I am not convinced this is the right level of signalling choice for this purpose. How do you stop propagation of such NLRIs around ? It would be pretty harmful if one router in Clos fabric will leak it and it breaks entire fabric - wouldn't you agree ? You at very min MUST enforce the NO-EXPORT/NO-ADVERTISE semantics for such SAFI which currently your draft seems to be missing. There are couple of alternatives to accomplish the same though: - using flag in dynamic capabilities - local poisoning of next hops - use of local pref/med (same as OSPF max metric:) - use of G-shut community or simply shutting the SAFIs. When you shut SAFI in one shot all paths learned are removed and best path (or multipath) recomputed. The potential "hit" would be on re-enabling it such that you need readvertise your underlay again. It is gracefull (no packet drops) as local forwarding can continue till everyone around stops sending you packets in a given table_id (corresponding to SAFI which has been shut down). Many thx, R. --001a113fbed20d775e0536f29b78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Amit,

I agree that recently BGP is = being stretched towards DC-fabric side to encompass various use cases.
<= br>
However, the way I see this draft, it can be useful for both, Inte= rnet and DC-fabrics. The main reason is to keep traffic drain procedure BGP= topology agnostic, exactly same as ISIS Overload-bit. Agree, BGP has a big= ger blast radius in Internet compared to ISIS but appropriate implementatio= n of the feature can provide good benefits.

=E2= =80=8BI don't think =E2=80=8Bthis is about "blast radius". IS= IS or OSPF are link state protocols and each node in the given flooding sco= pe computes its independent SPF hence flooding such information is a necess= ity for consistent forwarding.=C2=A0

Contrary to the above BGP is path/distance-vector where each= BGP speaker recomputes its bRIB and re-advertises it. Therefor for the use= case you have in mind all what is required is to signal in some way to a b= gp peer(s) that you may not want or want again to be in forwarding for a gi= ven SAFI.=C2=A0

You de= fined a new SAFI as well as new NLRI format to use for point to point signa= lling .. I am not convinced this is the right level of signalling choice fo= r this purpose. How do you stop propagation of such NLRIs around ? It would= be pretty harmful if one router in Clos fabric will leak it and it breaks = entire fabric - wouldn't you agree ? You at very min MUST enforce the N= O-EXPORT/NO-ADVERTISE semantics for such SAFI which currently your draft se= ems to be missing.=C2=A0

There are couple of alternatives to accomplish the same though:=C2=A0

- using flag in dynamic = capabilities=C2=A0
- local poisoning of next hops= =C2=A0
- use of local pref/med (same as OSPF max me= tric:)
- use of G-shut community=C2=A0
=C2=A0
or simply shutting the SAFIs. Wh= en you shut SAFI in one shot all paths learned are removed and best path (o= r multipath) recomputed. The potential "hit" would be on re-enabl= ing it such that you need readvertise your underlay again.=C2=A0

It is gracefull (no packet drops= ) as local forwarding can continue till everyone around stops sending you p= ackets in a given table_id (corresponding to SAFI which has been shut down)= .=C2=A0

Many thx,
R= .

--001a113fbed20d775e0536f29b78-- From nobody Wed Jul 6 00:48:21 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 866F512D731 for ; Wed, 6 Jul 2016 00:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 dlv5OFniYbhI for ; Wed, 6 Jul 2016 00:48:17 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 48BA612D6B3 for ; Wed, 6 Jul 2016 00:48:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.81.45; From: "Susan Hares" To: , "'John G. Scudder'" References: <068e01d1d714$c3002760$49007620$@ndzh.com> <12045_1467789454_577CB08E_12045_1818_1_53C29892C857584299CBF5D05346208A0F92D34C@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <12045_1467789454_577CB08E_12045_1818_1_53C29892C857584299CBF5D05346208A0F92D34C@OPEXCLILM21.corporate.adroot.infra.ftgroup> Date: Wed, 6 Jul 2016 03:47:36 -0400 Message-ID: <046301d1d75a$a9dbae30$fd930a90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0464_01D1D739.22CC7F30" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHKadK0KmVQ1y9U9ekYqI9scaqLPQJGaXzzoAetQcA= X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Keyur Patel $keyupate$'" , idr@ietf.org Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) 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, 06 Jul 2016 07:48:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0464_01D1D739.22CC7F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bruno, Keyur, and Wim: Thank you for your IPR Statements. We simply need the Jim Uttaro and Jeff Haas to respond to this email. Sue From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] Sent: Wednesday, July 6, 2016 3:18 AM To: Susan Hares; 'John G. Scudder' Cc: idr@ietf.org; 'Keyur Patel (keyupate)'; uttaro@att.com; 'Henderickx, Wim (Nokia - BE)'; jhaas@pfrc.org Subject: RE: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) Hi Sue, John, I'm not aware of IPR related to this draft. Regards, -- Bruno From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, July 06, 2016 1:27 AM To: idr@ietf.org; 'Keyur Patel (keyupate)'; uttaro@att.com; DECRAENE Bruno IMT/OLN; 'Henderickx, Wim (Nokia - BE)'; jhaas@pfrc.org Cc: 'John G. Scudder' Subject: RE: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) This ends the 2 week WG Adoption call for draft-keyupate-idr-bgp-attribute-announcement. The WG has adopted this draft. The Co-chairs forgot to do an IPR call on this draft. The authors should indicate whether they know of IPR on this draft. After we receive all the IPR statements, the authors will be able to upload this as draft-ietf-idr-bgp-attribute-announcement-00.txt. Sue Hares and John Scudder. ____________________________________________________________________________ _____________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ------=_NextPart_000_0464_01D1D739.22CC7F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bruno, Keyur, and Wim:

Thank you for your IPR = Statements. We simply need the Jim Uttaro and Jeff Haas to respond = to this email.

Sue =

From:= = bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] =
Sent: Wednesday, July 6, 2016 3:18 AM
To: Susan = Hares; 'John G. Scudder'
Cc: idr@ietf.org; 'Keyur Patel = (keyupate)'; uttaro@att.com; 'Henderickx, Wim (Nokia - BE)'; = jhaas@pfrc.org
Subject: RE: [Idr] WG Adoption of = draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call = (6/6 to 6/20)

Hi Sue, John,

I’m not aware of = IPR related to this draft.

Regards,

-- = Bruno

From:= Susan = Hares [mailto:shares@ndzh.com] =
Sent: Wednesday, July 06, 2016 1:27 AM
To: idr@ietf.org; 'Keyur Patel (keyupate)'; = uttaro@att.com; DECRAENE Bruno = IMT/OLN; 'Henderickx, Wim (Nokia - BE)'; jhaas@pfrc.org
Cc: 'John G. = Scudder'
Subject: RE: [Idr] WG Adoption of = draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call = (6/6 to 6/20)

This ends the 2 week WG Adoption call for = draft-keyupate-idr-bgp-attribute-announcement. The WG has adopted = this draft.

Sue Hares and John Scudder. =

_______________________________________________________________=
__________________________________________________________

Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc

pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles =
d'alteration,

Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.

This =
message and its attachments may contain confidential or privileged =
information that may be protected by =
law;

they should not be =
distributed, used or copied without =
authorisation.

If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.

As emails may be altered, Orange is not liable for messages =
that have been modified, changed or =
falsified.

Thank =
you.

------=_NextPart_000_0464_01D1D739.22CC7F30-- From nobody Wed Jul 6 06:00:28 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 B551A12D5AB for ; Wed, 6 Jul 2016 06:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 0MGwsZQ1DAmP for ; Wed, 6 Jul 2016 06:00:26 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C663612D1A5 for ; Wed, 6 Jul 2016 06:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1693; q=dns/txt; s=iport; t=1467810025; x=1469019625; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=20QyMzDJGnk4dvzTLmYqMajb9qG/ImflQ/2xA/oZ74Y=; b=B2rKQOib+HftI6YDKHYdVqcbHmE4nOrYh0Y3Fu06dDm06pUYn1EJ1ZaP 7HrnkuN46BrJBuBZFCReKN2S6DxJrce++xtG05XVD7wAfGqIGt8JpNvMP mI7PZJbz6aAnOcTsVzZqm7D2yiT1og3V621xADNm1S1tvMwJB4v1JxNWo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgBpAH1X/49dJa1dgz5WfAa5K4F3J?= =?us-ascii?q?IV0AoEpOBQBAQEBAQEBZSeETAEBBAE6PQcLAgEIGB4QMiUCBBOIKAgOvBcBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEchieBeIJVhECDLIIvBY4Eiw8BhgiCeoVEgWpOh?= =?us-ascii?q?AiIapAJAR42gjuBNW4Bh3J/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,318,1464652800"; d="scan'208";a="292766864" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 13:00:04 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u66D02Bd015259 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jul 2016 13:00:04 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 09:00:01 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 6 Jul 2016 09:00:02 -0400 From: "Stefano Previdi (sprevidi)" To: idr wg Thread-Topic: New Version Notification for draft-gredler-idr-bgp-ls-segment-routing-ext-03.txt Thread-Index: AQHR14X9SjHTejFfy0qhglpkXuxvTKALoJyA Date: Wed, 6 Jul 2016 13:00:02 +0000 Message-ID: <765F2F5B-CF4B-442D-AA87-3364E2E1856B@cisco.com> References: <20160706125729.7910.33892.idtracker@ietfa.amsl.com> In-Reply-To: <20160706125729.7910.33892.idtracker@ietfa.amsl.com> 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.61.175.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <2DB977A7CAA23D459B4A16045F599363@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] New Version Notification for draft-gredler-idr-bgp-ls-segment-routing-ext-03.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: Wed, 06 Jul 2016 13:00:28 -0000 Added extensions for prefix attributes as defined in RFC7794. Also, the authors believe this draft is ready for WG item adoption consider= ation. s. > On Jul 6, 2016, at 2:57 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-gredler-idr-bgp-ls-segment-routing-ext-03.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-gredler-idr-bgp-ls-segment-routing-ext > Revision: 03 > Title: BGP Link-State extensions for Segment Routing > Document date: 2016-07-06 > Group: Individual Submission > Pages: 33 > URL: https://www.ietf.org/internet-drafts/draft-gredler-idr-bg= p-ls-segment-routing-ext-03.txt > Status: https://datatracker.ietf.org/doc/draft-gredler-idr-bgp-ls= -segment-routing-ext/ > Htmlized: https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segm= ent-routing-ext-03 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-gredler-idr-bgp= -ls-segment-routing-ext-03 >=20 > Abstract: > Segment Routing (SR) allows for a flexible definition of end-to-end > paths within IGP topologies by encoding paths as sequences of > topological sub-paths, called "segments". These segments are > advertised by the link-state routing protocols (IS-IS, OSPF and > OSPFv3). >=20 > This draft defines extensions to the BGP Link-state address-family in > order to carry segment information via BGP. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Wed Jul 6 08:38:30 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 1152A12D5B7; Wed, 6 Jul 2016 08:38:29 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160706153829.26748.93309.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 08:38:29 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-05.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, 06 Jul 2016 15:38:29 -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 Traffic Engineering (TE) Policies and State using BGP-LS Authors : Stefano Previdi Jie Dong Mach(Guoyi) Chen Hannes Gredler Jeff Tantsura Filename : draft-ietf-idr-te-lsp-distribution-05.txt Pages : 26 Date : 2016-07-06 Abstract: This document describes a mechanism to collect the Traffic Engineering and Policy information that is locally available in a router and advertise it into BGP-LS updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distribution/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distribution-05 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 Jul 6 08:41:00 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 4136112D61B for ; Wed, 6 Jul 2016 08:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.927 X-Spam-Level: X-Spam-Status: No, score=-15.927 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, RP_MATCHES_RCVD=-1.426, 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 crajCg4JenjB for ; Wed, 6 Jul 2016 08:40:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8FF12D61A for ; Wed, 6 Jul 2016 08:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1549; q=dns/txt; s=iport; t=1467819622; x=1469029222; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ghTEovkauoLrwQOgmIeVK3/Sx/eX/0T+uLxCTf2MM4I=; b=X9fjse/6ubL+iKeWvh7+bzal4XThsdFeY3Pb3MQzNKOtD1xMqu0HErz0 kwMfACSTwWUTxqOtxAl2DthRQwWi4PjLgujnKVuc22qGV54pGgf1GfKbo RWK7mo+Ff8zCT3VDuKnOg5q79O+KVKLscWdks3JHGndfFErFeqW6qsUQg Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAnJn1X/49dJa1dgz5WfAa5EYF3J?= =?us-ascii?q?IV0AoEqOBQBAQEBAQEBZSeETAEBBAE6PQcLAgEIGB4QMiUCBBOIKAgOvCoBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEchieBeAiCTYRAgyyCLwWOBIsPAYYIiD4KgWBOh?= =?us-ascii?q?AiIapAJAR42g3BuAYdyfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,319,1464652800"; d="scan'208";a="125686838" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 15:40:21 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u66FeLJD004748 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jul 2016 15:40:21 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 11:40:20 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Wed, 6 Jul 2016 11:40:20 -0400 From: "Stefano Previdi (sprevidi)" To: idr wg Thread-Topic: New Version Notification for draft-ietf-idr-te-lsp-distribution-05.txt Thread-Index: AQHR15x6aFnBeN0w0ke+xSYil4t7VqALzToA Date: Wed, 6 Jul 2016 15:40:20 +0000 Message-ID: References: <20160706153829.26748.10794.idtracker@ietfa.amsl.com> In-Reply-To: <20160706153829.26748.10794.idtracker@ietfa.amsl.com> 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.61.175.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <32157DCF616C2F4CBBF6665C5C0F3AF3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] New Version Notification for draft-ietf-idr-te-lsp-distribution-05.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: Wed, 06 Jul 2016 15:40:59 -0000 Hi, added support of SR TE Policies (as defined in draft-previdi-idr-segment-ro= uting-te-policy) and local cross connect state. Thanks. s. > On Jul 6, 2016, at 5:38 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-idr-te-lsp-distribution-05.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-ietf-idr-te-lsp-distribution > Revision: 05 > Title: Distribution of Traffic Engineering (TE) Policies and State using= BGP-LS > Document date: 2016-07-06 > Group: idr > Pages: 26 > URL: https://www.ietf.org/internet-drafts/draft-ietf-idr-te-ls= p-distribution-05.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-di= stribution/ > Htmlized: https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distrib= ution-05 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-te-lsp= -distribution-05 >=20 > Abstract: > This document describes a mechanism to collect the Traffic > Engineering and Policy information that is locally available in a > router and advertise it into BGP-LS updates. Such information can be > used by external components for path computation, re-optimization, > service placement, network visualization, etc. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Wed Jul 6 10:34:23 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 3420B12D1B7 for ; Wed, 6 Jul 2016 10:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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 BTkKhwQoRCQQ for ; Wed, 6 Jul 2016 10:34:19 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d: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 5770012D0AA for ; Wed, 6 Jul 2016 10:34:19 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id e3so119540731qkd.0 for ; Wed, 06 Jul 2016 10:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zkZdktzpVHU1irEwYEYLDM4Lt0R+u2zismm3etT59qk=; b=gmUsKsM6QdFgY8fZG+DzoWgGWy5W9RsR6uhuwDxT0w1VY04l2y7Zaw8rxFjQz9ZVTn UBGMVv7gTA+kHZZwXPJVwISyFA4jSBmNtvaA3Cv50UwPWwgUi8Da8WfheJHEJrjn8Xyj YiCXAogr2WhJu816RtM93iC+OaWZOiJCOblBL9rFf25rvHneCmOgj+EorgFeLXTnp36E d+ydSBDfM08HzBGIL8ozySRHgxR36Kq50BRDqR1FzulEC5yKzpzIQ2tuVPZv5qdDKUe3 ugjexiJJt45t7Fr2jeAlSfCdMnlNYjlNo8IMhRPwjeKZmI47Vmq1PiUysT+efCfuWElH l+7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zkZdktzpVHU1irEwYEYLDM4Lt0R+u2zismm3etT59qk=; b=EoUF1F5Y7XqdH6C1Zuy3WeTEZL5vDnsA6M8waNadeH+vs7oZUVvWO2XBOqI7NTe5+m 04Y6/ggFveaZc0NrRHog7uNd8651Nh5YdvzFse0UJAydoXeGh0zG1dZR6QsMCgfdywXy 5Y8u/8ZOOgJKqHhggWHNehnoUeyVr6WcslcI6cIgTf+BRIqevRdumgyD7jvEFFOOGRTn U2sYaHfRY22TtwCHfC56CC8ag3OpRNF3RvKgMF1eWJkboXdpy9Cg4jErXorh9bCozBvM M+WTf0LuQP4T2GM31KnvrpswIuRk82v8C8/C4l6u6hoshG/gZ9qM5BUVa2a00KOV298a rVrg== X-Gm-Message-State: ALyK8tJBQ8HUR967xTDdOJxzoiA873YI6B3Tr6qKne2gglUinQ3Q03qhN/1YjynL0DbtYgGQZ/yIcgf4HxmObQ== X-Received: by 10.55.160.211 with SMTP id j202mr30956849qke.108.1467826458562; Wed, 06 Jul 2016 10:34:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.43.232 with HTTP; Wed, 6 Jul 2016 10:34:17 -0700 (PDT) In-Reply-To: References:

From: amit bhagat Date: Wed, 6 Jul 2016 10:34:17 -0700 Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary=001a114fadeca796eb0536fafadc Archived-At: Cc: idr wg Subject: Re: [Idr] Review Request for draft BGP Overload 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, 06 Jul 2016 17:34:21 -0000 --001a114fadeca796eb0536fafadc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Robert, There is no risk of leaking as the Capability will be exchanged with peers upon session establishment. What this feature also gives is monitoring Established neighbor-count. Consider a router connected to 10 peers and all 10 peers advertise exactly same prefixes in a CLOS fabric. Now, if 5 peer sessions go down, the capacity is effectively reduced to 50% while this router is still in the transit. This can cause congestion. Instead, the router can declare itself overloaded and the downstream routers then rely on other paths. The update advertisement delay can be an implementation detail. Thanks. Amit On Wed, Jul 6, 2016 at 12:34 AM, Robert Raszuk wrote: > Hi Amit, > > I agree that recently BGP is being stretched towards DC-fabric side to >> encompass various use cases. >> >> However, the way I see this draft, it can be useful for both, Internet >> and DC-fabrics. The main reason is to keep traffic drain procedure BGP >> topology agnostic, exactly same as ISIS Overload-bit. Agree, BGP has a >> bigger blast radius in Internet compared to ISIS but appropriate >> implementation of the feature can provide good benefits. >> > > > =E2=80=8BI don't think =E2=80=8Bthis is about "blast radius". ISIS or OSP= F are link state > protocols and each node in the given flooding scope computes its > independent SPF hence flooding such information is a necessity for > consistent forwarding. > > Contrary to the above BGP is path/distance-vector where each BGP speaker > recomputes its bRIB and re-advertises it. Therefor for the use case you > have in mind all what is required is to signal in some way to a bgp peer(= s) > that you may not want or want again to be in forwarding for a given SAFI. > > You defined a new SAFI as well as new NLRI format to use for point to > point signalling .. I am not convinced this is the right level of > signalling choice for this purpose. How do you stop propagation of such > NLRIs around ? It would be pretty harmful if one router in Clos fabric wi= ll > leak it and it breaks entire fabric - wouldn't you agree ? You at very mi= n > MUST enforce the NO-EXPORT/NO-ADVERTISE semantics for such SAFI which > currently your draft seems to be missing. > > There are couple of alternatives to accomplish the same though: > > - using flag in dynamic capabilities > - local poisoning of next hops > - use of local pref/med (same as OSPF max metric:) > - use of G-shut community > > or simply shutting the SAFIs. When you shut SAFI in one shot all paths > learned are removed and best path (or multipath) recomputed. The potentia= l > "hit" would be on re-enabling it such that you need readvertise your > underlay again. > > It is gracefull (no packet drops) as local forwarding can continue till > everyone around stops sending you packets in a given table_id > (corresponding to SAFI which has been shut down). > > Many thx, > R. > > --001a114fadeca796eb0536fafadc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Robert,

There is no risk of leak= ing as the Capability will be exchanged with peers upon session establishme= nt.

What this feature also gives is monitoring Establishe= d neighbor-count. Consider a router connected to 10 peers and all 10 peers = advertise exactly same prefixes in a CLOS fabric. Now, if 5 peer sessions g= o down, the capacity is effectively reduced to 50% while this router is sti= ll in the transit. This can cause congestion. Instead, the router can decla= re itself overloaded and the downstream routers then rely on other paths. T= he update advertisement delay can be an implementation detail.

Thanks.

Amit

On Wed, Jul 6, 2016 at 12:34 AM, Robert Rasz= uk <robert@raszuk.net> wrote:

Hi Amit,
I agre= e that recently BGP is being stretched towards DC-fabric side to encompass = various use cases.

However, the way I see this draft, it can b= e useful for both, Internet and DC-fabrics. The main reason is to keep traf= fic drain procedure BGP topology agnostic, exactly same as ISIS Overload-bi= t. Agree, BGP has a bigger blast radius in Internet compared to ISIS but ap= propriate implementation of the feature can provide good benefits.

=E2=80=8BI don't think =E2=80=8Bthis is about= "blast radius". ISIS or OSPF are link state protocols and each n= ode in the given flooding scope computes its independent SPF hence flooding= such information is a necessity for consistent forwarding.=C2=A0

Contrary to the above BGP is pa= th/distance-vector where each BGP speaker recomputes its bRIB and re-advert= ises it. Therefor for the use case you have in mind all what is required is= to signal in some way to a bgp peer(s) that you may not want or want again= to be in forwarding for a given SAFI.=C2=A0

You defined a new SAFI as well as new NLRI format to= use for point to point signalling .. I am not convinced this is the right = level of signalling choice for this purpose. How do you stop propagation of= such NLRIs around ? It would be pretty harmful if one router in Clos fabri= c will leak it and it breaks entire fabric - wouldn't you agree ? You a= t very min MUST enforce the NO-EXPORT/NO-ADVERTISE semantics for such SAFI = which currently your draft seems to be missing.=C2=A0

There are couple of alternatives to accompl= ish the same though:=C2=A0

- using flag in dynamic capabilities=C2=A0
- l= ocal poisoning of next hops=C2=A0
- use of local = pref/med (same as OSPF max metric:)
- use of G-shut= community=C2=A0
=C2=A0
or = simply shutting the SAFIs. When you shut SAFI in one shot all paths learned= are removed and best path (or multipath) recomputed. The potential "h= it" would be on re-enabling it such that you need readvertise your und= erlay again.=C2=A0

It = is gracefull (no packet drops) as local forwarding can continue till everyo= ne around stops sending you packets in a given table_id (corresponding to S= AFI which has been shut down).=C2=A0

Many thx,
R.

--001a114fadeca796eb0536fafadc-- From nobody Wed Jul 6 10:41:28 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 DCC2612D094 for ; Wed, 6 Jul 2016 10:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, 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 aG5EYOTMObua for ; Wed, 6 Jul 2016 10:41:24 -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 13147126B6D for ; Wed, 6 Jul 2016 10:41:24 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id l188so159310474lfe.2 for ; Wed, 06 Jul 2016 10:41:23 -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=uk5QG+TUmYwHGn2871iO5hSm7/JNLVFhfoc+PY32sHQ=; b=xaM0SdPQXUJSGUMA9LlswdGatoM/RbFt7TwIHeIarRVILPYBHIRbwuCWJXjxciqmbF vaOPX4s3MEqbtnnreTKQ1xTEWmXoFOoAdrDQcC2YksmBqrwY+5ujmZgneAdk9WUz5VxY wYQ5QH31NKGEj6CJMFtEs/MA7pTXg4zYHSg9Ip1LgMBmsNFTiR2kArW5pvfNvI7Yhl3X UdENcA3HRcNht0bmtry7lKjCKxYkHd1bfR6bJf5QjlzJi8hTdnVjahvFEwvD6O82Y0ad jn2OXkIHApDBftUeXcZO8ZHpjrJzWZBu9Ksk0E5oHoE3vMEysrQqZOSklhcuY83LeBUk /jNQ== 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=uk5QG+TUmYwHGn2871iO5hSm7/JNLVFhfoc+PY32sHQ=; b=k1nL4HxD90B2ADiK2gGNEfSYlZjOqeKd2jhmCGV1qr8EnIcBPoU/h8bh6/+e/CkfHo nkKcIa5n9cuK0XOp2tip1VvC5IdoGOh05OXipkZMO7d9Kdyy1IwNQOcXhzSO50YZm97M tz5XegH0n18Fb/sqlgB3H1SRlz5IcqFGl73xsDNg+g+zFwzK8ujatOZgFML9/HX+u+hS aIw64YK6SuDw66Ug6Ycge9ol3PcRMYc4zEyuxRgREmebhUXiWgSxs2zC888Cp7i0kdMU StAmEIChgDjMatKxDFjdJ4DBj5211AZR8ZAgiJnXDIF/5Fmb1iOM8chxIUbvw/teOa2a ntmA== X-Gm-Message-State: ALyK8tJudR1B3ooplfdDgMnPNQGUgMCEQnr241pL2SWxrA7AzPfsYwTKbbEUtPUrYa6yenEKkIpHuuyDjW68Ew== X-Received: by 10.25.84.65 with SMTP id i62mr7127356lfb.88.1467826882161; Wed, 06 Jul 2016 10:41:22 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.21.30 with HTTP; Wed, 6 Jul 2016 10:41:21 -0700 (PDT) In-Reply-To: References:

From: Robert Raszuk Date: Wed, 6 Jul 2016 19:41:21 +0200 X-Google-Sender-Auth: f2r1FZw3BsPrdO9aplMPh77t69U Message-ID: To: amit bhagat Content-Type: multipart/alternative; boundary=001a11411f28e730fd0536fb13fe Archived-At: Cc: idr wg Subject: Re: [Idr] Review Request for draft BGP Overload 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, 06 Jul 2016 17:41:27 -0000 --001a11411f28e730fd0536fb13fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Amit, BGP Capability is completely orthogonal. It only indicates who support this new SAFI. I am talking about the case where as this new SAFI which is needed only between *directly connected* peers will use generic BGP mechanism and will propage NLRIs across entire DC. It would be completely unnecessary yet your draft does not discuss this point. This is what I call "leaking". As far as signalling number of active peers to a peer I do not see how you encode this in the currently posted proposal nor it is clear what action such router should automatically do with that information. Honestly I would rather see the operator action here. Thx, R. On Wed, Jul 6, 2016 at 7:34 PM, amit bhagat wrote: > Hi Robert, > > There is no risk of leaking as the Capability will be exchanged with peer= s > upon session establishment. > > What this feature also gives is monitoring Established neighbor-count. > Consider a router connected to 10 peers and all 10 peers advertise exactl= y > same prefixes in a CLOS fabric. Now, if 5 peer sessions go down, the > capacity is effectively reduced to 50% while this router is still in the > transit. This can cause congestion. Instead, the router can declare itsel= f > overloaded and the downstream routers then rely on other paths. The updat= e > advertisement delay can be an implementation detail. > > Thanks. > Amit > > On Wed, Jul 6, 2016 at 12:34 AM, Robert Raszuk wrote: > >> Hi Amit, >> >> I agree that recently BGP is being stretched towards DC-fabric side to >>> encompass various use cases. >>> >>> However, the way I see this draft, it can be useful for both, Internet >>> and DC-fabrics. The main reason is to keep traffic drain procedure BGP >>> topology agnostic, exactly same as ISIS Overload-bit. Agree, BGP has a >>> bigger blast radius in Internet compared to ISIS but appropriate >>> implementation of the feature can provide good benefits. >>> >> >> >> =E2=80=8BI don't think =E2=80=8Bthis is about "blast radius". ISIS or OS= PF are link state >> protocols and each node in the given flooding scope computes its >> independent SPF hence flooding such information is a necessity for >> consistent forwarding. >> >> Contrary to the above BGP is path/distance-vector where each BGP speaker >> recomputes its bRIB and re-advertises it. Therefor for the use case you >> have in mind all what is required is to signal in some way to a bgp peer= (s) >> that you may not want or want again to be in forwarding for a given SAFI= . >> >> You defined a new SAFI as well as new NLRI format to use for point to >> point signalling .. I am not convinced this is the right level of >> signalling choice for this purpose. How do you stop propagation of such >> NLRIs around ? It would be pretty harmful if one router in Clos fabric w= ill >> leak it and it breaks entire fabric - wouldn't you agree ? You at very m= in >> MUST enforce the NO-EXPORT/NO-ADVERTISE semantics for such SAFI which >> currently your draft seems to be missing. >> >> There are couple of alternatives to accomplish the same though: >> >> - using flag in dynamic capabilities >> - local poisoning of next hops >> - use of local pref/med (same as OSPF max metric:) >> - use of G-shut community >> >> or simply shutting the SAFIs. When you shut SAFI in one shot all paths >> learned are removed and best path (or multipath) recomputed. The potenti= al >> "hit" would be on re-enabling it such that you need readvertise your >> underlay again. >> >> It is gracefull (no packet drops) as local forwarding can continue till >> everyone around stops sending you packets in a given table_id >> (corresponding to SAFI which has been shut down). >> >> Many thx, >> R. >> >> > --001a11411f28e730fd0536fb13fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Amit,

BGP Capability is completely orthogonal. It only ind= icates who support this new SAFI. I am talking about the case where =C2=A0a= s this new SAFI which is needed only between *directly connected* peers wil= l use generic BGP mechanism and will propage NLRIs across entire DC. It wou= ld be completely unnecessary yet your draft does not discuss this point. Th= is is what I call "leaking".=C2=A0

As far as signalling number of active peers to a pee= r I do not see how you encode this in the currently posted proposal nor it = is clear what action such router should automatically do with that informat= ion. Honestly I would rather see the operator action here.=C2=A0

Thx,

R.<= /div>

On Wed, Jul 6, 2016 at = 7:34 PM, amit bhagat <scet.amit@gmail.com> wrote:

Hi Robert,

There is no risk of leaking as the Capability will be exchanged with peer= s upon session establishment.

What this feature also give= s is monitoring Established neighbor-count. Consider a router connected to = 10 peers and all 10 peers advertise exactly same prefixes in a CLOS fabric.= Now, if 5 peer sessions go down, the capacity is effectively reduced to 50= % while this router is still in the transit. This can cause congestion. Ins= tead, the router can declare itself overloaded and the downstream routers t= hen rely on other paths. The update advertisement delay can be an implement= ation detail.

Thanks.

Amit

On W= ed, Jul 6, 2016 at 12:34 AM, Robert Raszuk <robert@raszuk.net> wrote:

Hi Amit,

=
I agree that recently BGP is being stretched towards D= C-fabric side to encompass various use cases.

However, the way= I see this draft, it can be useful for both, Internet and DC-fabrics. The = main reason is to keep traffic drain procedure BGP topology agnostic, exact= ly same as ISIS Overload-bit. Agree, BGP has a bigger blast radius in Inter= net compared to ISIS but appropriate implementation of the feature can prov= ide good benefits.

=

=E2=80=8BI don't t= hink =E2=80=8Bthis is about "blast radius". ISIS or OSPF are link= state protocols and each node in the given flooding scope computes its ind= ependent SPF hence flooding such information is a necessity for consistent = forwarding.=C2=A0

Cont= rary to the above BGP is path/distance-vector where each BGP speaker recomp= utes its bRIB and re-advertises it. Therefor for the use case you have in m= ind all what is required is to signal in some way to a bgp peer(s) that you= may not want or want again to be in forwarding for a given SAFI.=C2=A0

You defined a new SAFI as= well as new NLRI format to use for point to point signalling .. I am not c= onvinced this is the right level of signalling choice for this purpose. How= do you stop propagation of such NLRIs around ? It would be pretty harmful = if one router in Clos fabric will leak it and it breaks entire fabric - wou= ldn't you agree ? You at very min MUST enforce the NO-EXPORT/NO-ADVERTI= SE semantics for such SAFI which currently your draft seems to be missing.= =C2=A0

There are coupl= e of alternatives to accomplish the same though:=C2=A0

- using flag in dynamic capabilities=C2=A0=
- local poisoning of next hops=C2=A0
- use of local pref/med (same as OSPF max metric:)
- use of G-shut community=C2=A0
=C2=A0
or simply shutting the SAFIs. When you shut SAFI in = one shot all paths learned are removed and best path (or multipath) recompu= ted. The potential "hit" would be on re-enabling it such that you= need readvertise your underlay again.=C2=A0

It is gracefull (no packet drops) as local forwardin= g can continue till everyone around stops sending you packets in a given ta= ble_id (corresponding to SAFI which has been shut down).=C2=A0

Many thx,
R.

--001a11411f28e730fd0536fb13fe-- From nobody Thu Jul 7 06:53:46 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 600B512D1DE; Thu, 7 Jul 2016 06:53:43 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707135343.23713.62123.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 06:53:43 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-reserved-extended-communities-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: Thu, 07 Jul 2016 13:53:43 -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 : Assigned BGP extended communities Authors : Bruno Decraene Pierre Francois Filename : draft-ietf-idr-reserved-extended-communities-09.txt Pages : 6 Date : 2016-07-07 Abstract: This document defines an IANA registry in order to assign non- transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide a control over inter-AS community advertisement as, per RFC RFC 4360, they are not transitive across Autonomous System boundaries. For that purpose, this document defines the use of the reserved Autonomous System number 0.65535 in the non-transitive generic four- octet AS specific extended community type. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-reserved-extended-communities/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-reserved-extended-communities-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-reserved-extended-communities-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 Thu Jul 7 06:55:54 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 50EC312D09F for ; Thu, 7 Jul 2016 06:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 TT3ZSs-BQzRt for ; Thu, 7 Jul 2016 06:55:51 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCC612D603 for ; Thu, 7 Jul 2016 06:55:51 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 157BBC013E for ; Thu, 7 Jul 2016 15:55:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id EA32020057 for ; Thu, 7 Jul 2016 15:55:49 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0301.000; Thu, 7 Jul 2016 15:55:49 +0200 From: To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-reserved-extended-communities-09.txt Thread-Index: AQHR2Fb9EvV7tgRwJk6+NMB0Oq8ngKAM/WZw Date: Thu, 7 Jul 2016 13:55:48 +0000 Message-ID: <5465_1467899750_577E5F65_5465_11655_1_53C29892C857584299CBF5D05346208A0F94131B@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <20160707135343.23713.62123.idtracker@ietfa.amsl.com> In-Reply-To: <20160707135343.23713.62123.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-reserved-extended-communities-09.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: Thu, 07 Jul 2016 13:55:53 -0000 Hi all, Just a refresh, following discussions on GROW WG related to non-transitive = well-known communities. -- Bruno > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org > Sent: Thursday, July 07, 2016 3:54 PM > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-reserved-extended-communities-0= 9.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Inter-Domain Routing of the IETF. >=20 > Title : Assigned BGP extended communities > Authors : Bruno Decraene > Pierre Francois > Filename : draft-ietf-idr-reserved-extended-communities-09.txt > Pages : 6 > Date : 2016-07-07 >=20 > Abstract: > This document defines an IANA registry in order to assign non- > transitive extended communities from. These are similar to the > existing well-known BGP communities defined in RFC 1997 but provide a > control over inter-AS community advertisement as, per RFC RFC 4360, > they are not transitive across Autonomous System boundaries. >=20 > For that purpose, this document defines the use of the reserved > Autonomous System number 0.65535 in the non-transitive generic four- > octet AS specific extended community type. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-reserved-extended-communi= ties/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-idr-reserved-extended-communities-= 09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-reserved-extended-comm= unities-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ 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. From nobody Thu Jul 7 10:17:38 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 727AE12D0E4 for ; Thu, 7 Jul 2016 10:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 7tntUEogjPtQ for ; Thu, 7 Jul 2016 10:17:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 95E4012D590 for ; Thu, 7 Jul 2016 10:17:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3178E1E3C3; Thu, 7 Jul 2016 13:17:51 -0400 (EDT) Date: Thu, 7 Jul 2016 13:17:51 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20160707171750.GB3711@pfrc.org> References: <068e01d1d714$c3002760$49007620$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <068e01d1d714$c3002760$49007620$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr@ietf.org, "'Keyur Patel $keyupate$'" , 'Bruno Decraene' Subject: Re: [Idr] WG Adoption of draft-keyupate-idr-bgp-attribute-announcement - 2 week WG Adoption call (6/6 to 6/20) 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, 07 Jul 2016 17:17:37 -0000 On Tue, Jul 05, 2016 at 07:27:12PM -0400, Susan Hares wrote: > This ends the 2 week WG Adoption call for > draft-keyupate-idr-bgp-attribute-announcement. The WG has adopted this > draft. > > The Co-chairs forgot to do an IPR call on this draft. The authors should > indicate whether they know of IPR on this draft. After we receive all the > IPR statements, the authors will be able to upload this as > draft-ietf-idr-bgp-attribute-announcement-00.txt. I am unaware of any IPR on this document. -- Jeff From nobody Thu Jul 7 10:24: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 98FF312D60B for ; Thu, 7 Jul 2016 10:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 7mkWjudKq3fp for ; Thu, 7 Jul 2016 10:24:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D3D1B12D0E4 for ; Thu, 7 Jul 2016 10:24:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7A8471E3C3; Thu, 7 Jul 2016 13:25:10 -0400 (EDT) Date: Thu, 7 Jul 2016 13:25:10 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20160707172510.GC3711@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Idr] Early allocation for ext-opt-param [internet-drafts@ietf.org: I-D Action: draft-ietf-idr-ext-opt-param-05.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: Thu, 07 Jul 2016 17:24:56 -0000 A brief note as I'm catching up in my email: It does not appear that IANA has an early allocation request for the 255 code point for this draft. Given that the feature is deployed, that seems problematic. If the authors and our AD believe this will pass through IESG fast enough, we can probably skip such a request. -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- Date: Tue, 28 Jun 2016 19:10:49 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ext-opt-param-05.txt 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 : Extended Optional Parameters Length for BGP OPEN Message Authors : Enke Chen John Scudder Filename : draft-ietf-idr-ext-opt-param-05.txt Pages : 6 Date : 2016-06-28 Abstract: The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP Capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concern about this limitation. In this document we update RFC 4271 by extending the BGP OPEN length field in a backward-compatible manner. The Parameter Length field of individual Optional Parameters is similarly extended. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-ext-opt-param-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ext-opt-param-05 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/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ----- End forwarded message ----- From nobody Thu Jul 7 10:33:38 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 D4E8512D1A7 for ; Thu, 7 Jul 2016 10:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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 evKzRPfJzQdy for ; Thu, 7 Jul 2016 10:33:29 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 4158212D572 for ; Thu, 7 Jul 2016 10:33:29 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id m2so12008609qtd.1 for ; Thu, 07 Jul 2016 10:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=swkEyJaX/0JPwy+Up/9VXQgaBV6Of8McrjS29zRIdzk=; b=p06SxB5V71Y26MOsW0fgsKO7Ep3bxeX/prSDwhVW4Y7A/GzHLPjW8DKjTdNgyQpah4 S0JXzGoxsWxqohBw/EKkD1ZvGLr7Cs5rZhzeXx49q5K7Umhpfs5mkzyLiqummGwzIVhS R4XBVQgvwIBCAwnIT/9uS5fWlcalqsyE3wk4CToHnQ5JEW1aFrzVjninWOeiJufhH4zt 26owKDNMaTuFSBGIRf0FIxONnCnxnH67QMjcQEcziGEOoEkC446ATwRRUnSde1DdSYR4 rOVdRSVyPNkhiKMnrUkvfuphrM81neHVng5WDqUFvEPOW3qCCgoheELw6qMiCVx3m1n5 F1/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=swkEyJaX/0JPwy+Up/9VXQgaBV6Of8McrjS29zRIdzk=; b=Db8egqA/WoPQSWMhK+rDQxtvAXXazJO0ZEe7F0Fsa3kRcc3AeslhT2w9j95+WJksyl 1bq2inQhh+iM2t9EQu5ef5z2YoLc10qO03jILW9uJZ7wii4g0SK0ghN7M/ibmMfYR2Yl uyv1as1ciuHv+Yi1LYWc0yUvYWjrf0MfqG48aO4DgKv2vjNhqLaYNhGPGQA8MPJOt/A7 /5Zb+lvvfW1kLydUa4c3zQRx7TrknEFarEVxNXFNPdvGTtoyMwAUtYXJzZJ5wHr5d47B xqA9todd/wEGeiJG0z2g4MuEQW3OUhgRlZxJB3/Us/2XMERTbetqf15sDPD5BguBvjja jG7A== X-Gm-Message-State: ALyK8tJlXOvsBlvjW98elKYzVJXCr9FK8F1KZPTF+xzULcBeOxwEH5UlcQbN0A7d7spMgdRc1h9AwjCgdbssoQ== X-Received: by 10.200.37.150 with SMTP id e22mr2003543qte.37.1467912808399; Thu, 07 Jul 2016 10:33:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.43.232 with HTTP; Thu, 7 Jul 2016 10:33:27 -0700 (PDT) In-Reply-To: References:

From: amit bhagat

--001a11c04ca881896205370f154f-- From nobody Fri Jul 8 03:29: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 75B2F12D665 for ; Fri, 8 Jul 2016 03:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] 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 CTLRWALYM40Z for ; Fri, 8 Jul 2016 03:29:32 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 A7FBC12D63C for ; Fri, 8 Jul 2016 03:29:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.72; From: "Susan Hares" To: References: <20160708102740.32127.50534.idtracker@ietfa.amsl.com> In-Reply-To: <20160708102740.32127.50534.idtracker@ietfa.amsl.com> Date: Fri, 8 Jul 2016 06:28:54 -0400 Message-ID: <008001d1d903$87a6a630$96f3f290$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHaWnduqGUJ7AohcqThQyqhgB8nHp/9UbJw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] FW: New Version Notification for draft-liang-idr-flowspec-v1-time-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: Fri, 08 Jul 2016 10:29:33 -0000 This time filter that combines with the other RFC5575bis filters. The = authors welcome comments on this draft.=20 Sue, Jianjie, and LIang -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, July 8, 2016 6:28 AM To: Jianjie You; Qiandeng Liang; liangqiandeng; Susan Hares Subject: New Version Notification for = draft-liang-idr-flowspec-v1-time-00.txt A new version of I-D, draft-liang-idr-flowspec-v1-time-00.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-liang-idr-flowspec-v1-time Revision: 00 Title: BGP Flow Specification Filter Component for Time Constraints Document date: 2016-07-08 Group: Individual Submission Pages: 6 URL: = https://www.ietf.org/internet-drafts/draft-liang-idr-flowspec-v1-time-00.= txt Status: = https://datatracker.ietf.org/doc/draft-liang-idr-flowspec-v1-time/ Htmlized: = https://tools.ietf.org/html/draft-liang-idr-flowspec-v1-time-00 Abstract: BGP flow specification version 1 (RFC5575) describes the distribution of traffic filter policy (traffic filters and actions) which are distributed via BGP to BGP peers to support the following 3 applications: (1) mitigation of Denial of Service (DoS), (2) traffic filtering in BGP/MPLS VPNs, and (3) centralized traffic control for networks with SDN or NFV controllers. A BGP Flow Filter that combines packet filter with time may provide an ability to for these three applications to have a flow filter operate for only a specific time. This document proposes a new BGP Flow specification filter based on time. = =20 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. The IETF Secretariat From nobody Fri Jul 8 03:36: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 92AAC12D739 for ; Fri, 8 Jul 2016 03:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.439 X-Spam-Level: **** X-Spam-Status: No, score=4.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] 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 1XNg8lxqlS_y for ; Fri, 8 Jul 2016 03:36:39 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 4187F12D5DE for ; Fri, 8 Jul 2016 03:36:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.72; From: "Susan Hares" To: "'John G. Scudder'" , Date: Fri, 8 Jul 2016 06:36:07 -0400 Message-ID: <008201d1d904$89530130$9bf90390$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01D1D8E3.0243F940" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHZBGDb1bLvCih+QbGfyXVlJNljLg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IDR presentaton slot 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, 08 Jul 2016 10:36:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0083_01D1D8E3.0243F940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit John: May I please have time for 4 flow specification drafts presentations: 1) Flow specification v2 [3 slides, title, 2 text] 2) RFC5575bis - 2 variants: draft-hares-rfc5575bis, draft-hr-rfc5575bis [4 slides: title: 3 text] 3) Flow Specification Time filter - draft-liang-idr-flowspec-v1-time and draft-liang-idr-flowspec-v3 [3 slides, title, 2 text, 1 QA] Total: slides: 10 slides, total time 15 minutes (less if need to) . Sue Hares ------=_NextPart_000_0083_01D1D8E3.0243F940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John: =

May I please have time for 4 flow specification drafts = presentations:

1) = Flow specification v2 [3 slides, title, 2 = text]

2) = RFC5575bis – 2 variants: = draft-hares-rfc5575bis, draft-hr-rfc5575bis [4 slides: title: 3 = text]

3) = Flow Specification Time filter - = draft-liang-idr-flowspec-v1-time and = draft-liang-idr-flowspec-v3

[3 = slides, title, 2 text, 1 QA]

Total: = slides: 10 slides, total time 15 minutes (less if need to) . =

Sue Hares

------=_NextPart_000_0083_01D1D8E3.0243F940-- From nobody Fri Jul 8 08:02: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 0C48C12B047 for ; Fri, 8 Jul 2016 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 tMirpktgh9GE for ; Fri, 8 Jul 2016 08:02:56 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1423E12D769 for ; Fri, 8 Jul 2016 08:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=218; q=dns/txt; s=iport; t=1467990170; x=1469199770; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=/F/+zUzPRtd7bIts2aBHDG+Rcmh0Z5jU7YSOY6cKG38=; b=RqE6dtjr8FTWE0KgIhDnMxZC8NBIWI2D+pQWZVACqei1EIZxNx6S3Uu2 QPVs/HHKdVaEFM6fzroy0SgmnV4ulmrECCkTpkVTV8Q+JnK4zcKam1Neq nn/zbFNHSlAQb1xeHe4XmyG2buw7bLWpSnDrsGfVYnTcYO0I2OyjzrhtI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVBgCCv39X/4MNJK1bgz5WgQK5DoF7I?= =?us-ascii?q?oV2HoELOhIBAQEBAQEBZSeEUyMRRRIBFgwCJgIEMBUSBAENiDUOrkGPPQEBAQE?= =?us-ascii?q?BAQEDAQEBAQEBAQEaBYEBixWGIIJaBZkUAYYLiEOBVAGNV2+PHgElBCuDcYkhf?= =?us-ascii?q?wEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,330,1464652800"; d="scan'208";a="295285027" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2016 15:02:50 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u68F2o99004064 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jul 2016 15:02:50 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; Fri, 8 Jul 2016 11:02:49 -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; Fri, 8 Jul 2016 11:02:49 -0400 From: "Acee Lindem (acee)" To: Susan Hares , John Scudder Thread-Topic: IDR Session Slot Request Thread-Index: AQHR2SnKHHa63GQ4GEuJn2prDiOnng== Date: Fri, 8 Jul 2016 15:02:49 +0000 Message-ID: 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.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IDR List Subject: [Idr] IDR Session Slot Request 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, 08 Jul 2016 15:02:58 -0000 SGkgU3VlLCBKb2huLA0KDQpJIHdvdWxkIGxpa2UgYSAxMCBtaW51dGUgc2xvdCB0byBwcmVzZW50 IG91ciBuZXcgZHJhZnQ6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWtleXVwYXRlLWlkci1iZ3Atc3BmLw0KDQpUaGFua3MsDQpBY2VlIA0KDQo= From nobody Fri Jul 8 08:48:19 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 C3B5112D0B5 for ; Fri, 8 Jul 2016 08:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] 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 cF0ftpP9eUxT for ; Fri, 8 Jul 2016 08:48:16 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 A6C6812D549 for ; Fri, 8 Jul 2016 08:48:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.72; From: "Susan Hares" To: "'Acee Lindem $acee$'" , "'John Scudder'" References: In-Reply-To: Date: Fri, 8 Jul 2016 11:47:43 -0400 Message-ID: <01a201d1d930$1189dbc0$349d9340$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLZUY3p7vHktXOl/lY0p4GxW46HOp3/vPkA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'IDR List' Subject: Re: [Idr] IDR Session Slot Request 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, 08 Jul 2016 15:48:17 -0000 Acee: I will add you to the list. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Friday, July 8, 2016 11:03 AM To: Susan Hares; John Scudder Cc: IDR List Subject: [Idr] IDR Session Slot Request Hi Sue, John, I would like a 10 minute slot to present our new draft: https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-spf/ Thanks, Acee _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jul 8 08:52:30 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 6FE8212D7D2 for ; Fri, 8 Jul 2016 08:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, 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 Hw8kbZC51LYa for ; Fri, 8 Jul 2016 08:52:13 -0700 (PDT) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 0195812D7D6 for ; Fri, 8 Jul 2016 08:51:58 -0700 (PDT) Received: by mail-lf0-x243.google.com with SMTP id a2so7997959lfe.3 for ; Fri, 08 Jul 2016 08:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=Ia/KcfbRRLyG/U3c5JcHAUJYcvQGIOVkLG+/COt2QOM=; b=dpTVe8Ik+czS2ZgoCQTz/Uuo4nZ5EWIV5K4WYk4t9IdlZYA3zopuFqzGG9xaoFWgiX yTRBozUXii2XrIRMV4dWM/19SqCRPsAEFlaJlZv+mgolzz++DLSqU9MmJ/YahL6PoVXg t67awBaqe9nhZLs8DvFuS07/ucaV2QX49m7CSDuOWuslMs2ZRX+ZqUCKQ3hkqefJ9Ap6 awPghu+BgTBf2n7EskNfTJVCwUx2MWshJA+YXFsJobo/1mZrBUYUw/Bvz+St52zwNHBH YI7gQyPpmC4CuHeoFGkb5vrK8Z1bNwZhN+5/oBIGrHoaDtcbkk2QiH056g38io65byev QBHw== 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:from:date:message-id:subject :to:cc; bh=Ia/KcfbRRLyG/U3c5JcHAUJYcvQGIOVkLG+/COt2QOM=; b=HugfF+jW1816SHlrZ5zGmdSWjISR2QaXD2EKlNV6IudNyeHsMwyqoK3QrV2FCBd21Z aoPtWzPXHUUjhEPlxFVf5xJ1RT2DzNxdMs22WmjzO0Hea1RD4LQywS4RXXRicx0oL4QV emJVju1y4CXJ1zp4x0qdFzgXg6sdkSytEYBPmm0YLKZJL5ZBsnBFi+rAMzRrtfZvjuH7 v4jTe1iqgfPJWi6OtpDFqEZSxlDs7xO6841/rp++o7GVvNJs3rGY09nU1c4f1dUGCb9F fdIH1GYOom1ZIISi5x53v2+kT2bVfmo5vM67VMdwKXgIyQml0gOkYhwF5mbTJG5YfVVW i2+Q== X-Gm-Message-State: ALyK8tJ9m1mY4O7mjmqKFKvaM6xCleubdJ6VmouDU9VjO5p5Rr41I9QvpZWFChp/6lJacCKCIbLF/EDykC1kzg== X-Received: by 10.46.33.80 with SMTP id h77mr1666535ljh.29.1467993117101; Fri, 08 Jul 2016 08:51:57 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.18.225 with HTTP; Fri, 8 Jul 2016 08:51:56 -0700 (PDT) From: Robert Raszuk Date: Fri, 8 Jul 2016 17:51:56 +0200 X-Google-Sender-Auth: qUiayxR_DCszy7xVT6kvZqHWfnw Message-ID: To: "Keyur Patel (keyupate)"

Robert.

--001a1142c9b24714ca053721c8dc-- From nobody Fri Jul 8 09:08:39 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 B4FC512B02E; Fri, 8 Jul 2016 09:08:34 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708160834.32176.49579.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 09:08:34 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-vandevelde-idr-flowspec-path-redirect-03.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: Fri, 08 Jul 2016 16:08:35 -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 Wim Henderickx Keyur Patel Arjun Sreekantiah Zhenbin Li Shunwan Zhuang Nan Wu Filename : draft-vandevelde-idr-flowspec-path-redirect-03.txt Pages : 12 Date : 2016-07-08 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-vandevelde-idr-flowspec-path-redirect/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-vandevelde-idr-flowspec-path-redirect-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-vandevelde-idr-flowspec-path-redirect-03 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 Fri Jul 8 09:13:26 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 4A33A12D504; Fri, 8 Jul 2016 09:13:24 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708161324.32205.25819.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 09:13:24 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-optimal-route-reflection-12.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: Fri, 08 Jul 2016 16:13:24 -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 Optimal Route Reflection (BGP-ORR) Authors : Robert Raszuk Christian Cassar Erik Aman Bruno Decraene Stephane Litkowski Kevin Wang Filename : draft-ietf-idr-bgp-optimal-route-reflection-12.txt Pages : 12 Date : 2016-07-08 Abstract: This document proposes a solution for BGP route reflectors to allow them to choose the best path their clients would have chosen under the same conditions, without requiring further state or any new features to be placed on the clients. This facilitates, for example, best exit point policy (hot potato routing). This solution is primarily applicable in deployments using centralized route reflectors. The solution relies upon all route reflectors learning all paths which are eligible for consideration. Best path selection is performed in each route reflector based on a configured virtual location in the IGP. The location can be the same for all clients or different per peer/update group or per peer. Best path selection can also be performed based on user configured policies in each route reflector. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-optimal-route-reflection-12 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 Fri Jul 8 09:21:32 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 160B712D0C9; Fri, 8 Jul 2016 09:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=icloud.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 LGlFVwBRL_W1; Fri, 8 Jul 2016 09:21:29 -0700 (PDT) Received: from st13p11im-asmtp003.me.com (st13p11im-asmtp003.me.com [17.164.40.218]) (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 C6B6D12D0A4; Fri, 8 Jul 2016 09:21:28 -0700 (PDT) Received: from process-dkim-sign-daemon.st13p11im-asmtp003.me.com by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OA0006007HEP000@st13p11im-asmtp003.me.com>; Fri, 08 Jul 2016 16:21:09 +0000 (GMT) Received: from 174-16-209-161.hlrn.qwest.net (unknown [128.127.164.82]) by st13p11im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OA000CLT82YDS00@st13p11im-asmtp003.me.com>; Fri, 08 Jul 2016 16:21:07 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-08_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1607080152 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.3 $3124$) From: Gunter Van De Velde In-reply-to: <152e01d1d5ee$0c4c1320$24e43960$@ndzh.com> Date: Fri, 08 Jul 2016 18:20:57 +0200 Content-transfer-encoding: quoted-printable Message-id: References: <152e01d1d5ee$0c4c1320$24e43960$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1467994869; bh=eZ7uVLxxdzlllwjRhBdF/WLzXzqiG3ZDrFSqzQvo6ck=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=oXIn6UnNLJGmtV4o8iHTv31Tfjyjut8Kpct5iSG+8d0MgJFnmjt2dn5KDS8Aep4KQ 2qVYPhCwZp8Zigk/pIs9ygnvFkOkhWWfIXR/rRtWCAz/EmdP2E216FQumU6m6vJ23q ZhCr7NoQvIneovSoOouXErKUGl2u90HASEIKq1ioSQCTt3FP8HaR9CGsB+HS1ugmFS IjkS6VRFPCS4F9F4JpRX7X7MVy9kQEutRdaS1/O6n/r/igzDrcr50FyKOGLKnosdA9 CxwSZX8lHk/uE9TNvcGICVcJCQJ6UTTWVC5gGo54+eK/SxumXxWBxQk1XcDhaT/788 SFOUI9IjLz4ug== Archived-At: Cc: idr@ietf.org, "John G. Scudder" , idr chairs Subject: Re: [Idr] Presentation slot 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, 08 Jul 2016 16:21:31 -0000 Hi Sue, John, As discussed the draft-vandevelde-idr-flowspec-path-redirect-03 has been = posted and is now the merged document=20 draft-vandevelde-idr-flowspec-path-redirect-02 and = draft-li-idr-flowspec-redirect-generalized-sid-00 . Maybe a 5 minute slot to discuss the current state could be helpful for = the WG. Brgds, G/ > On 04 Jul 2016, at 14:17, Susan Hares wrote: >=20 > =20 > IETF 96 is drawing near. For those who would like to present at IETF = 96, please reply to this message (making sure to keep both chairs), and = request a slot. =20 > =20 > Sue and John=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jul 8 09:22:36 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 2F58412D0C9 for ; Fri, 8 Jul 2016 09:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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.426, 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 2vZKxlX6IRxX for ; Fri, 8 Jul 2016 09:22:32 -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 3A09012D0A8 for ; Fri, 8 Jul 2016 09:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20889; q=dns/txt; s=iport; t=1467994952; x=1469204552; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0PMCpYYQ5fEWD2ok48+A47JvdnnGh9GbYX6aX9/5xOg=; b=fMNbTva700JgvtVnBuBpbfxAzyiNgUp1eFoUkGQzj/GV9uDCTG2gWi9M 9n17BNrXIewRie18rwj2QclYDnwzqeyDmS5dZfK78IDTkRSX2qBWNr88K CN5QK56pU6LSDDHAt1uKnd/79ULyJ4YNdLKUHPKQUM6unzp0sxaFmrpGC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AgCL0n9X/4sNJK1bgnBOgVIGrHmHE?= =?us-ascii?q?YUEgXuGGAIcgQw4FAEBAQEBAQFlJ4RMAQEFI0QSEAIBCBEDAQIoAwICAh8RFAk?= =?us-ascii?q?IAgQBDQWIFgMXrm6LBQ2EGwEBAQEBAQEBAQEBAQEBAQEBAQEBARyJcYEDgkOBW?= =?us-ascii?q?kSCYYJaBZNahQY0AYw6ghSBaoRYiGqIGodzAR42g3Fuh25FfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,330,1464652800"; d="scan'208,217";a="294704602" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2016 16:22:31 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u68GMUYo012265 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jul 2016 16:22:31 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 12:22:29 -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; Fri, 8 Jul 2016 12:22:29 -0400 From: "Acee Lindem (acee)" To: Robert Raszuk , "Keyur Patel (keyupate)" , "Abhay Roy (akr)" , "Derek Man-Kit Yeung (myeung)" , "Venu Venugopal (venuv)" Thread-Topic: Shortest Path Routing Extensions for BGP Protocol Thread-Index: AQHR2TCrYqWhF/FuxECJ8BfBQYUWB6AOt3SA Date: Fri, 8 Jul 2016 16:22:29 +0000 Message-ID: References: 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.196] Content-Type: multipart/alternative; boundary="_000_D3A547856931Eaceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: idr wg Subject: Re: [Idr] Shortest Path Routing Extensions for BGP Protocol 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, 08 Jul 2016 16:22:34 -0000 --_000_D3A547856931Eaceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpUaGFua3MgZm9yIGVuZ2FnaW5n4oCmDQoNCkZyb206IDxycmFzenVrQGdt YWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+PiBvbiBiZWhhbGYgb2YgUm9iZXJ0IFJh c3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkRhdGU6 IEZyaWRheSwgSnVseSA4LCAyMDE2IGF0IDExOjUxIEFNDQpUbzogIktleXVyIFBhdGVsIChrZXl1 cGF0ZSkiIDxrZXl1cGF0ZUBjaXNjby5jb208bWFpbHRvOmtleXVwYXRlQGNpc2NvLmNvbT4+LCBB Y2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4sICJBYmhh eSBSb3kgKGFrcikiIDxha3JAY2lzY28uY29tPG1haWx0bzpha3JAY2lzY28uY29tPj4sICJEZXJl ayBNYW4tS2l0IFlldW5nIChteWV1bmcpIiA8bXlldW5nQGNpc2NvLmNvbTxtYWlsdG86bXlldW5n QGNpc2NvLmNvbT4+LCAiVmVudSBWZW51Z29wYWwgKHZlbnV2KSIgPHZlbnV2QGNpc2NvLmNvbTxt YWlsdG86dmVudXZAY2lzY28uY29tPj4NCkNjOiBJRFIgTGlzdCA8aWRyQGlldGYub3JnPG1haWx0 bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogU2hvcnRlc3QgUGF0aCBSb3V0aW5nIEV4dGVuc2lv bnMgZm9yIEJHUCBQcm90b2NvbA0KDQpIaSwNCg0KSSBoYXZlIHJldmlld2VkIHlvdXIgcHJvcG9z YWwuDQoNClR1cm5pbmcgcGF0aCB2ZWN0b3Igb3IgZGlzdGFuY2UgdmVjdG9yIHByb3RvY29sIGlu dG8gbGluayBzdGF0ZSBjYXJyaWVyIGlzIG5vIGRvdWJ0IGEgYm9sZCBpZGVhIDopLg0KDQrigJxG b3J0dW5lIGJlZnJpZW5kcyB0aGUgYm9sZC7igJ0gLUVtaWx5IERpY2tpbnNvbg0KDQoNCkVmZmVj dGl2ZWx5IHdoYXQgeW91IGFyZSBwcm9wb3NpbmcgaXMgdG8gdXNlIEJHUCBUQ1Agc2Vzc2lvbnMg dG8gcHJvcGFnYXRlIGxpbmsgc3RhdGUgZGF0YWJhc2UgY3JlYXRpbmcgZmlyc3QgImxpbmsgdmVj dG9yIHByb3RvY29sIiAhDQoNCkZvciBzdGFydCBJIGhhdmUgZmV3IHF1ZXN0aW9uczoNCg0KUTE6 DQoNClJGQzc3NTIgaGFzIGdvbmUgdmlhIGxvdCBvZiBlZmZvcnRzIChlc3BlY2lhbGx5IHNlY3Rp b25zIDMuMiBhbmQgdXApIHRvIGluY2x1ZGUgbnVtYmVyIG9mIE9TUEYgb3IgSVNJUyBzcGVjaWZp YyBlbmNvZGluZ3MuIEluIHlvdXIgcHJvcG9zYWwgeW91IG1lbnRpb25lZCBPU1BGIHR3aWNlIGFu ZCBub3QgZXZlbiBvbmNlIElTSVMuIERvZXMgaXQgbWVhbiB0aGF0IHlvdSBhcmUgbm90IGdvaW5n IHRvIHVzZSBhbGwgZW5jb2RpbmcgZm9yIHNwZWNpZmljIElHUHMgYXMgZGVmaW5lZCBpbiBSRkM3 NzUyID8NCg0KV2UgYXJlIHVzaW5nIHRoZSBCR1AgUHJvdG9jb2wtSUQgZGVmaW5lZCBmb3IgQkdQ LUVQRS4gVGhlIElBTkEgcmVxdWVzdCB3aWxsIGJlIGdlbmVyYWxpemVkIGZyb20g4oCcQkdQLUVQ ReKAnSB0byDigJxCR1DigJ0gaW4gc3VwcG9ydCBvZiBTZWdtZW50IFJvdXRpbmcgYW5kIG90aGVy IGVuaGFuY2VtZW50cy4gVGhlIEJHUC1MUyBOTFJJIGFyZSBzcGVjaWZpYyBCR1AgYW5kIG5vdCBl aXRoZXIgSVMtSVMgb3IgT1NQRi4NCg0KDQpRMjoNCg0KV2hvIGNyZWF0ZXMgYW5kIG1haW50YWlu cyBMU0RCIGluIGVhY2ggQkdQIHNwZWFrZXIgPyBBcmUgeW91IHBsYW5uaW5nIHRvIHJ1biBPU1BG IGFuZCBvciBJU0lTIGV4Y2VwdCBkaXNhYmxlIGl0IHRvIGVzdGFibGlzaCBhbnkgYWRqYWNpZW5j aWVzID8NCg0KSeKAmXZlIHNlZW4gZGVzaWducyBsaWtlIHRoaXMgaW4gbXkgdGltZSBidXQgaGF2 ZSBuZXZlciBiZWVuIG9mIGEgZmFuIG9mIHRoZW0gO14pLiBCR1Agd2lsbCBkbyB0aGUgU1BGIGRp cmVjdGx5IGFuZCBtYWludGFpbiB0aGUgU1BULiBZb3XigJlsbCBub3RlIHRoYXQgYSBzaW1wbGlm aWVkIFNQRiBpcyBhbHJlYWR5IGRvbmUgZm9yIE9SUi4NCg0KDQpRMzoNCg0KQ3VycmVudGx5IHRo ZXJlIGFyZSBhbHJlYWR5IHRvIG1vZGVscyB0byBidWlsZCBEQ3Mgd2l0aCBCR1AgLi4uIG9uZSB1 c2VzIEJHUCB0byBjcmVhdGUgb25seSBsZWFuIHVuZGVybGF5IHRoZSBvdGhlciBpcyB0byB1c2Ug QkdQIGZvciBib3RoIHVuZGVybGF5IGFuZCB0ZW5hbnRzIChleGFtcGxlIHByb2plY3QgQ2FsaWNv IGZvciB0aGUgbGF0dGVyKS4gV2l0aCB0aGF0IHNjYWxlIHdpc2UgSSB0aGluayB5b3VyIHByb3Bv c2FsIHdpbGwgd29yayBncmVhdCBmb3IgdGhlIGZvcm1lci4gSG93ZXZlciBJIGRvIGhhdmUgY29u Y2VybnMgYWJvdXQgdXNpbmcgeW91ciBtb2RlbCBmb3IgdGhlIGxhdHRlciB3aGVyZSBzYXkgMTAs MDAwIG9yIDEwMCwwMDAgLzMycyBvciAvMTI4cyBmcm9tIGVhY2ggVk1zIGFyZSBpbmplY3RlZCBh bmQgeW91IG5lZWQgdG8gY29uc3RydWN0IFNQVCB3aXRoIGFsbCBvZiB0aG9zZS4NCg0KU2ltaWxh ciB0byB0aG9zZSBkZXNpZ25zLCB0aGUgU1BUIGNvdWxkIGJlIGxpbWl0ZWQgdG8gdGhlIHVuZGVy bGF5LiBIb3dldmVyLCBpZiB0aGVyZSBpcyBubyByZXF1aXJlbWVudCBmb3IgdGhlIGJlbmVmaXRz IG9mIEwyIG9yIEwzIFZQTnMsIEkgc2VlIG5vIHJlYXNvbiB3aHkgdGhlc2UgMTAwS3Mgb2YgbGVh ZnMgVk0gcHJlZml4ZXMgaW4gREMgY2VudGVyIGNvdWxkbuKAmXQgYmUgc3VwcG9ydGVkLg0KDQoN ClE0Og0KDQpSZWxhdGVkIHRvIFEzIGluIHlvdXIgbW9kZWwgYW5kIHNheSBmbGF0IERDIHJvdXRp bmcgZWFjaCBjb21wdXRlIG5vZGUgb3RoZXIgdGhlbiBqdXN0IGluamVjdGluZyAxMHMgb2YgLzMy cyBhbmQgYmVpbmcgImRvbmUiIG5vdyBiZWNvbWVzIGFuIElHUCBub2RlLiBTaW5jZSB5b3VyIGRv Y3VtZW50IGV4cGxpY2l0ZWx5IHRhcmdldHMgTWFzc2l2ZWx5IFNjYWxlZCBEYXRhIENlbnRlcnMg KE1TRENzKSBJIGFtIGNvbmNlcm5lZCB0aGF0IGhhdmluZyAxMDAsMDAwKyBJR1Agbm9kZXMgYW5k IGluIG1hbnkgY2FzZSBtdWNoIG1vcmUgaXMgbm90IHRoZSBiZXN0IGlkZWEuDQoNCjEwMEsrIHN3 aXRjaGVzIGluIGEgc2luZ2xlIERDIGZhYnJpYyAoaS5lLiwgQkdQIHJvdXRpbmcgZG9tYWluKT8g SSBoYXZlIHNvbWUgZXhwZXJpZW5jZSBpbiBsaW5rLXN0YXRlIHByb3RvY29scyBhbmQgSSBjYW4g dGVsbCB5b3UgdGhhdCBPU1BGIGlzIEkvTyBib3VuZCBtYWlubHkgZHVlIHRvIHRoZSBmbG9vZGlu Zy4gSWYgZG9uZSByaWdodCwgdGhlIFNQRiBjYWxjdWxhdGlvbiBjYW4gYmUgZG9uZSB3aXRoIG1p bmltYWwgY29tcHV0YXRpb24uIFdoaWxlIEJHUC1MUyBpc27igJl0IHRoZSB3b3JsZCdzIG1vc3Qg Y29tcGFjdCBlbmNvZGluZywgaXQgaXMgY29tcGxldGVseSBpbmNyZW1lbnRhbC4NCg0KDQpRNToN Cg0KSGF2ZSB5b3UgY29uc2lkZXJlZCBqdXN0IHByb3Bvc2luZyBhbiBPU1BGIHJvdXRlIHJlZmxl Y3RvciBpbnN0ZWFkIHdpdGhvdXQgc3R1ZmZpbmcgQkdQIGludG8gdGhlIG1peCA/IEFzIHNvbWUg b2YgeW91IHBlcmhhcHMgcmVtZW1iZXIgdGhlIHdvcmsgb24gdGhpcyBzdGFydGVkIGFyb3VuZCB5 ZWFyIDIwMDAgdG8gb3B0aW1pemUgUEUtQ0UgQ1NDIGRlcGxveW1lbnRzIDopIEl0IHNlZW1zIHRv IG1lIHZlcnkgcmV1c2FibGUgZm9yIHRoaXMgZ29hbC4NCg0KV2UgbG9va2VkIGF0IGxvdHMgb2Yg YWx0ZXJuYXRpdmVzIGFuZCB0aGlzIG9uZSBzZWVtZWQgbGlrZSB0aGUgYmVzdCBvbmUuIFBsZWFz ZSBwYXNzIG1lIGEgcG9pbnRlciB0byB0aGUgd29yayB5b3UgbWVudGlvbi4NCg0KVGhhbmtzLA0K QWNlZQ0KDQoNCg0KQmVzdCByZWdhcmRzLA0KUm9iZXJ0Lg0KDQo= --_000_D3A547856931Eaceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K SGkgUm9iZXJ0LCZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpUaGFua3MgZm9yIGVuZ2Fn aW5n4oCmPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4N CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFs aWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVS LUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBp bjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9S REVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZsdDs8YSBocmVmPSJtYWlsdG86cnJhc3p1 a0BnbWFpbC5jb20iPnJyYXN6dWtAZ21haWwuY29tPC9hPiZndDsgb24gYmVoYWxmIG9mIFJvYmVy dCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCI+cm9iZXJ0QHJh c3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRl OiA8L3NwYW4+RnJpZGF5LCBKdWx5IDgsIDIwMTYgYXQgMTE6NTEgQU08YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtLZXl1ciBQYXRlbCAoa2V5dXBh dGUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2V5dXBhdGVAY2lzY28uY29tIj5rZXl1cGF0 ZUBjaXNjby5jb208L2E+Jmd0OywgQWNlZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1haWx0bzphY2Vl QGNpc2NvLmNvbSI+YWNlZUBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7QWJoYXkgUm95IChha3Ip JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWtyQGNpc2NvLmNvbSI+YWtyQGNpc2NvLmNvbTwv YT4mZ3Q7LA0KICZxdW90O0RlcmVrIE1hbi1LaXQgWWV1bmcgKG15ZXVuZykmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpteWV1bmdAY2lzY28uY29tIj5teWV1bmdAY2lzY28uY29tPC9hPiZndDss ICZxdW90O1ZlbnUgVmVudWdvcGFsICh2ZW51dikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2 ZW51dkBjaXNjby5jb20iPnZlbnV2QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+SURSIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0 bzppZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5TaG9ydGVzdCBQYXRoIFJvdXRpbmcgRXh0 ZW5zaW9ucyBmb3IgQkdQIFByb3RvY29sPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQpIaSw8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6 c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0i Zm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4N CkkgaGF2ZSByZXZpZXdlZCB5b3VyIHByb3Bvc2FsLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2Rl ZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250 LXNpemU6c21hbGwiPg0KVHVybmluZyBwYXRoIHZlY3RvciBvciBkaXN0YW5jZSB2ZWN0b3IgcHJv dG9jb2wgaW50byBsaW5rIHN0YXRlIGNhcnJpZXIgaXMgbm8gZG91YnQgYSBib2xkIGlkZWEgOiku PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj7igJxGb3J0dW5lIGJlZnJpZW5kcyB0aGUgYm9sZC7igJ0g LUVtaWx5IERpY2tpbnNvbjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9O X0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5H OjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIi Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhl bHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Es c2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KRWZmZWN0aXZlbHkgd2hhdCB5b3UgYXJlIHBy b3Bvc2luZyBpcyB0byB1c2UgQkdQIFRDUCBzZXNzaW9ucyB0byBwcm9wYWdhdGUgbGluayBzdGF0 ZSBkYXRhYmFzZSBjcmVhdGluZyBmaXJzdCAmcXVvdDtsaW5rIHZlY3RvciBwcm90b2NvbCZxdW90 OyAhPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6 YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhl bHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpGb3Igc3RhcnQgSSBoYXZlIGZl dyBxdWVzdGlvbnM6PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxi cj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpRMTombmJzcDs8 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlh bCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClJGQzc3NTIgaGFzIGdvbmUgdmlhIGxv dCBvZiBlZmZvcnRzIChlc3BlY2lhbGx5IHNlY3Rpb25zIDMuMiBhbmQgdXApIHRvIGluY2x1ZGUg bnVtYmVyIG9mIE9TUEYgb3IgSVNJUyBzcGVjaWZpYyBlbmNvZGluZ3MuIEluIHlvdXIgcHJvcG9z YWwgeW91IG1lbnRpb25lZCBPU1BGIHR3aWNlIGFuZCBub3QgZXZlbiBvbmNlIElTSVMuIERvZXMg aXQgbWVhbiB0aGF0IHlvdSBhcmUgbm90IGdvaW5nIHRvIHVzZSBhbGwgZW5jb2RpbmcgZm9yIHNw ZWNpZmljDQogSUdQcyBhcyBkZWZpbmVkIGluIFJGQzc3NTIgPyZuYnNwOzwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+V2UgYXJlIHVzaW5nIHRoZSBCR1AgUHJvdG9jb2wtSUQgZGVmaW5lZCBmb3IgQkdQ LUVQRS4gVGhlIElBTkEgcmVxdWVzdCB3aWxsIGJlIGdlbmVyYWxpemVkIGZyb20g4oCcQkdQLUVQ ReKAnSB0byDigJxCR1DigJ0gaW4gc3VwcG9ydCBvZiBTZWdtZW50IFJvdXRpbmcgYW5kIG90aGVy IGVuaGFuY2VtZW50cy4gVGhlIEJHUC1MUyBOTFJJIGFyZSBzcGVjaWZpYyBCR1AgYW5kIG5vdCBl aXRoZXIgSVMtSVMgb3IgT1NQRi4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Ymxv Y2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJP UkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAw IDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9u dC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpz bWFsbCI+DQpRMjombmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwi Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCldobyBj cmVhdGVzIGFuZCBtYWludGFpbnMgTFNEQiBpbiBlYWNoIEJHUCBzcGVha2VyID8gQXJlIHlvdSBw bGFubmluZyB0byBydW4gT1NQRiBhbmQgb3IgSVNJUyBleGNlcHQgZGlzYWJsZSBpdCB0byBlc3Rh Ymxpc2ggYW55IGFkamFjaWVuY2llcyA/Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J4oCZ dmUgc2VlbiBkZXNpZ25zIGxpa2UgdGhpcyBpbiBteSB0aW1lIGJ1dCBoYXZlIG5ldmVyIGJlZW4g b2YgYSBmYW4gb2YgdGhlbSA7XikuIEJHUCB3aWxsIGRvIHRoZSBTUEYgZGlyZWN0bHkgYW5kIG1h aW50YWluIHRoZSBTUFQuIFlvdeKAmWxsIG5vdGUgdGhhdCBhIHNpbXBsaWZpZWQgU1BGIGlzIGFs cmVhZHkgZG9uZSBmb3IgT1JSLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFu IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2Rl ZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250 LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBz dHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNt YWxsIj4NClEzOiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KQ3VycmVu dGx5IHRoZXJlIGFyZSBhbHJlYWR5IHRvIG1vZGVscyB0byBidWlsZCBEQ3Mgd2l0aCBCR1AgLi4u IG9uZSB1c2VzIEJHUCB0byBjcmVhdGUgb25seSBsZWFuIHVuZGVybGF5IHRoZSBvdGhlciBpcyB0 byB1c2UgQkdQIGZvciBib3RoIHVuZGVybGF5IGFuZCB0ZW5hbnRzIChleGFtcGxlIHByb2plY3Qg Q2FsaWNvIGZvciB0aGUgbGF0dGVyKS4gV2l0aCB0aGF0IHNjYWxlIHdpc2UgSSB0aGluayB5b3Vy IHByb3Bvc2FsIHdpbGwgd29yayBncmVhdA0KIGZvciB0aGUgZm9ybWVyLiBIb3dldmVyIEkgZG8g aGF2ZSBjb25jZXJucyBhYm91dCB1c2luZyB5b3VyIG1vZGVsIGZvciB0aGUgbGF0dGVyIHdoZXJl IHNheSAxMCwwMDAgb3IgMTAwLDAwMCAvMzJzIG9yIC8xMjhzIGZyb20gZWFjaCBWTXMgYXJlIGlu amVjdGVkIGFuZCB5b3UgbmVlZCB0byBjb25zdHJ1Y3QgU1BUIHdpdGggYWxsIG9mIHRob3NlLiZu YnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFu Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2ltaWxhciB0byB0aG9zZSBkZXNpZ25zLCB0aGUg U1BUIGNvdWxkIGJlIGxpbWl0ZWQgdG8gdGhlIHVuZGVybGF5LiBIb3dldmVyLCBpZiB0aGVyZSBp cyBubyByZXF1aXJlbWVudCBmb3IgdGhlIGJlbmVmaXRzIG9mIEwyIG9yIEwzIFZQTnMsIEkgc2Vl IG5vIHJlYXNvbiB3aHkgdGhlc2UgMTAwS3Mgb2YgbGVhZnMgVk0gcHJlZml4ZXMgaW4gREMgY2Vu dGVyIGNvdWxkbuKAmXQgYmUgc3VwcG9ydGVkLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBz dHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJH SU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9 ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1z ZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9k ZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9u dC1zaXplOnNtYWxsIj4NClE0OiZuYnNwOzxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQi IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6 c21hbGwiPg0KUmVsYXRlZCB0byBRMyBpbiB5b3VyIG1vZGVsIGFuZCBzYXkgZmxhdCBEQyByb3V0 aW5nIGVhY2ggY29tcHV0ZSBub2RlIG90aGVyIHRoZW4ganVzdCBpbmplY3RpbmcgMTBzIG9mIC8z MnMgYW5kIGJlaW5nICZxdW90O2RvbmUmcXVvdDsgbm93IGJlY29tZXMgYW4gSUdQIG5vZGUuIFNp bmNlIHlvdXIgZG9jdW1lbnQgZXhwbGljaXRlbHkgdGFyZ2V0cyZuYnNwO01hc3NpdmVseSBTY2Fs ZWQgRGF0YSBDZW50ZXJzIChNU0RDcykgSSBhbSBjb25jZXJuZWQgdGhhdCBoYXZpbmcgMTAwLDAw MCYjNDM7DQogSUdQIG5vZGVzIGFuZCBpbiBtYW55IGNhc2UgbXVjaCBtb3JlIGlzIG5vdCB0aGUg YmVzdCBpZGVhLiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+MTAwSyYjNDM7IHN3aXRjaGVz IGluIGEgc2luZ2xlIERDIGZhYnJpYyAoaS5lLiwgQkdQIHJvdXRpbmcgZG9tYWluKT8gSSBoYXZl IHNvbWUgZXhwZXJpZW5jZSBpbiBsaW5rLXN0YXRlIHByb3RvY29scyBhbmQgSSBjYW4gdGVsbCB5 b3UgdGhhdCBPU1BGIGlzIEkvTyBib3VuZCBtYWlubHkgZHVlIHRvIHRoZSBmbG9vZGluZy4gSWYg ZG9uZSByaWdodCwgdGhlIFNQRiBjYWxjdWxhdGlvbiBjYW4gYmUgZG9uZSB3aXRoIG1pbmltYWwg Y29tcHV0YXRpb24uDQogV2hpbGUgQkdQLUxTIGlzbuKAmXQgdGhlIHdvcmxkJ3MgbW9zdCBjb21w YWN0IGVuY29kaW5nLCBpdCBpcyBjb21wbGV0ZWx5IGluY3JlbWVudGFsLiZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElP Tl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElO RzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRy Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxo ZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClE1OiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtm b250LXNpemU6c21hbGwiPg0KSGF2ZSB5b3UgY29uc2lkZXJlZCBqdXN0IHByb3Bvc2luZyBhbiBP U1BGIHJvdXRlIHJlZmxlY3RvciBpbnN0ZWFkIHdpdGhvdXQgc3R1ZmZpbmcgQkdQIGludG8gdGhl IG1peCA/IEFzIHNvbWUgb2YgeW91IHBlcmhhcHMgcmVtZW1iZXIgdGhlIHdvcmsgb24gdGhpcyBz dGFydGVkIGFyb3VuZCB5ZWFyIDIwMDAgdG8gb3B0aW1pemUgUEUtQ0UgQ1NDIGRlcGxveW1lbnRz IDopIEl0IHNlZW1zIHRvIG1lIHZlcnkgcmV1c2FibGUgZm9yIHRoaXMgZ29hbC48L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PldlIGxvb2tlZCBhdCBsb3RzIG9mIGFsdGVybmF0aXZlcyBhbmQgdGhpcyBv bmUgc2VlbWVkIGxpa2UgdGhlIGJlc3Qgb25lLiBQbGVhc2UgcGFzcyBtZSBhIHBvaW50ZXIgdG8g dGhlIHdvcmsgeW91IG1lbnRpb24uJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWUmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURE SU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KQmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRp diBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGlj YSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpSb2JlcnQuPC9kaXY+DQo8ZGl2IGNsYXNz PSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D3A547856931Eaceeciscocom_-- From nobody Fri Jul 8 10:21:19 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 B494412D5C4; Fri, 8 Jul 2016 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] 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 1MXwVOtcDkn7; Fri, 8 Jul 2016 10:21:07 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 5AA5A12D589; Fri, 8 Jul 2016 10:21:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.72; From: "Susan Hares" To: "'Gunter Van De Velde'" References: <152e01d1d5ee$0c4c1320$24e43960$@ndzh.com> In-Reply-To: Date: Fri, 8 Jul 2016 13:20:34 -0400 Message-ID: <021301d1d93d$09ce1bf0$1d6a53d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLN6h0I1kMMkzKOeCmbR8vdTJayoQIun9fSngUwyzA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, "'John G. Scudder'" , 'idr chairs' Subject: Re: [Idr] Presentation slot 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, 08 Jul 2016 17:21:11 -0000 Gunter: You have a time slot. Sue -----Original Message----- From: Gunter Van De Velde [mailto:guntervandeveldecc@icloud.com] Sent: Friday, July 8, 2016 12:21 PM To: Susan Hares Cc: idr@ietf.org; idr chairs; John G. Scudder Subject: Re: [Idr] Presentation slot Hi Sue, John, As discussed the draft-vandevelde-idr-flowspec-path-redirect-03 has been posted and is now the merged document draft-vandevelde-idr-flowspec-path-redirect-02 and draft-li-idr-flowspec-redirect-generalized-sid-00 . Maybe a 5 minute slot to discuss the current state could be helpful for the WG. Brgds, G/ > On 04 Jul 2016, at 14:17, Susan Hares wrote: > > > IETF 96 is drawing near. For those who would like to present at IETF 96, please reply to this message (making sure to keep both chairs), and request a slot. > > Sue and John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jul 8 10:34: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 21A8F12D787; Fri, 8 Jul 2016 10:34:50 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708173450.32087.66387.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 10:34:50 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as4octet-extcomm-generic-subtype-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: Fri, 08 Jul 2016 17:34:50 -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 : Generic Subtype for BGP Four-octet AS specific extended community Authors : Dhananjaya Rao Pradosh Mohapatra Jeffrey Haas Filename : draft-ietf-idr-as4octet-extcomm-generic-subtype-09.txt Pages : 6 Date : 2016-07-08 Abstract: Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific BGP extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as4octet-extcomm-generic-subtype/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-as4octet-extcomm-generic-subtype-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 Fri Jul 8 12:46:12 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 3446212D90F; Fri, 8 Jul 2016 12:45:50 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708194550.32201.86394.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 12:45:50 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-attribute-announcement-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: Fri, 08 Jul 2016 19:45:50 -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 : Constrain Attribute announcement within BGP Authors : Keyur Patel James Uttaro Bruno Decraene Wim Henderickx Jeff Haas Filename : draft-ietf-idr-bgp-attribute-announcement-00.txt Pages : 9 Date : 2016-07-08 Abstract: [RFC4271] defines four different categories of BGP Path attributes. The different Path attribute categories can be identified by the attribute flag values. These flags help identify if an attribute is optional or well-known, Transitive or non-Transitive, Partial, or of an Extended length type. BGP attribute announcement depends on whether an attribute is a well-known or optional, and whether an attribute is a transitive or non-transitive. BGP implementations MUST recognize all well-known attributes. The well-known attributes are always Transitive. It is not required for BGP implementations to recognise all the Optional attributes. The Optional attributes could be Transitive or Non-Transitive. BGP implementations MUST store and forward any Unknown Optional Transitive attributes and ignore and drop any Unknown Optional Non-Transitive attributes. Currently, there is no way to confine the scope of Path attributes within a given Autonomous System (AS) or a given BGP member-AS in Confederation. This draft defines attribute extensions that help confine the scope of Optional attributes within a given AS or a given BGP member-AS in Confederation The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-attribute-announcement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-attribute-announcement-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 Fri Jul 8 14:32:36 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 670BE12D916; Fri, 8 Jul 2016 14:32:27 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708213227.32135.69537.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 14:32:27 -0700 Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, The IESG , draft-ietf-idr-ix-bgp-route-server@ietf.org, shares@ndzh.com, rfc-editor@rfc-editor.org Subject: [Idr] Protocol Action: 'Internet Exchange BGP Route Server' to Proposed Standard (draft-ietf-idr-ix-bgp-route-server-12.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: Fri, 08 Jul 2016 21:32:27 -0000 The IESG has approved the following document: - 'Internet Exchange BGP Route Server' (draft-ietf-idr-ix-bgp-route-server-12.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-ix-bgp-route-server/ Technical Summary This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more external BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. Working Group Summary The document has been discussed for 2-3 years in the IDR and the GROW working group. There is a "companion" document from the grow WG: draft-ietf-grow-ix-bgp-route-server-operations. Document Quality Yes, implementations from cisco, BIRD and Quaga exist. The details of an implementation report are here: http://trac.tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-ix-bgp-route-server%20implementations Personnel Document Shepherd: Susan Hares Responsible AD: Alvaro Retana From nobody Fri Jul 8 14:35:35 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 3E85E12D928; Fri, 8 Jul 2016 14:35:34 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708213534.32176.47384.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 14:35:34 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-route-leak-detection-mitigation-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: Fri, 08 Jul 2016 21:35:34 -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 : Methods for Detection and Mitigation of BGP Route Leaks Authors : Kotikalapudi Sriram Doug Montgomery Brian Dickson Keyur Patel Andrei Robachevsky Filename : draft-ietf-idr-route-leak-detection-mitigation-04.txt Pages : 22 Date : 2016-07-08 Abstract: [I-D.ietf-grow-route-leak-problem-definition] provides a definition of the route leak problem, and also enumerates several types of route leaks. This document first examines which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811]. It is recognized that OV offers a limited detection and mitigation capability against route leaks. This document specifies enhancements that significantly extend the route-leak prevention, detection, and mitigation capabilities of BGP. One solution component involves carrying a per-hop route-leak protection (RLP) field in BGP updates. The RLP field is proposed be carried in a new optional transitive attribute, called BGP RLP attribute. The solution is meant to be initially implemented as an enhancement of BGP without requiring BGPsec [I-D.ietf-sidr-bgpsec-protocol]. However, when BGPsec is deployed in the future, the solution can be incorporated in BGPsec, enabling cryptographic protection for the RLP field. That would be one way of implementing the proposed solution in a secure way. The document also includes a stopgap method for detection and mitigation of route leaks for an intermediate phase when OV is deployed but BGP protocol on the wire is unchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-route-leak-detection-mitigation-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 Fri Jul 8 15:57: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 82AAD12D0A3; Fri, 8 Jul 2016 15:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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.426, 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 WPGWWoVNfjhB; Fri, 8 Jul 2016 15:57:12 -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 E053C12B028; Fri, 8 Jul 2016 15:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=572; q=dns/txt; s=iport; t=1468018631; x=1469228231; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=rR366fFmPiyS57HnghpNGBag+cuE5JURlbV55mOZH10=; b=OnRZbPZDmf+6jWprq/Wz9/ppEnSifsu5KRBgRf9CwCvX70OX1Ikma/GD F3IucIo45RIMFw/P9Ux2DveEoVNwxus0BJ+lcdMIdPxIVmWoNyChmwBE7 t48XFa5ymUvOOchD1Gs1AJlNN8b5jY1b37PjyAB+fdOnXE2I8gxm8mz1S g=; X-IronPort-AV: E=Sophos;i="5.28,332,1464652800"; d="scan'208";a="293660187" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2016 22:57:11 +0000 Received: from [10.41.57.152] ([10.41.57.152]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u68MvAgv015794; Fri, 8 Jul 2016 22:57:10 GMT To: Susan Hares , "'John G. Scudder'" References: <152e01d1d5ee$0c4c1320$24e43960$@ndzh.com> From: Enke Chen Message-ID: <33a8ae6f-1498-f6bb-0135-7215eb7842be@cisco.com> Date: Fri, 8 Jul 2016 15:57:10 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <152e01d1d5ee$0c4c1320$24e43960$@ndzh.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: idr@ietf.org, Robert Raszuk , 'idr chairs' Subject: Re: [Idr] Presentation slot 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, 08 Jul 2016 22:57:13 -0000 Hi, Sue and John: I would like to ask for 15-minutes to present the following draft at the upcoming IETF in Berlin: draft-chen-idr-geo-coordinates-01 Thanks. -- Enke On 7/4/16 5:17 AM, Susan Hares wrote: > > > IETF 96 is drawing near. For those who would like to present at IETF 96, please reply to this message (making sure to keep both chairs), and request a slot. > > > > Sue and John > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Fri Jul 8 16:48:56 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 CC77D12D87C; Fri, 8 Jul 2016 16:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] 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 cHyA2DzW75BC; Fri, 8 Jul 2016 16:48:52 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [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 0EFDA12D896; Fri, 8 Jul 2016 16:48:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.20; From: "Susan Hares" To: "'Enke Chen'" , "'John G. Scudder'" References: <152e01d1d5ee$0c4c1320$24e43960$@ndzh.com> <33a8ae6f-1498-f6bb-0135-7215eb7842be@cisco.com> In-Reply-To: <33a8ae6f-1498-f6bb-0135-7215eb7842be@cisco.com> Date: Fri, 8 Jul 2016 19:48:17 -0400 Message-ID: <004d01d1d973$342ac660$9c805320$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLN6h0I1kMMkzKOeCmbR8vdTJayoQKV8PvNngJiZcA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, 'Robert Raszuk' , 'idr chairs' Subject: Re: [Idr] Presentation slot 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, 08 Jul 2016 23:48:54 -0000 Enke: I'm thrilled to have you presenting at IDR once again. Your slot will be between 10-15 minutes (depending on how crowded the agenda is). Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Enke Chen Sent: Friday, July 8, 2016 6:57 PM To: Susan Hares; 'John G. Scudder' Cc: idr@ietf.org; Robert Raszuk; 'idr chairs' Subject: Re: [Idr] Presentation slot Hi, Sue and John: I would like to ask for 15-minutes to present the following draft at the upcoming IETF in Berlin: draft-chen-idr-geo-coordinates-01 Thanks. -- Enke On 7/4/16 5:17 AM, Susan Hares wrote: > > > IETF 96 is drawing near. For those who would like to present at IETF 96, please reply to this message (making sure to keep both chairs), and request a slot. > > > > Sue and John > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Fri Jul 8 17:45: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 14B1F12B051 for ; Fri, 8 Jul 2016 17:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 8qck49sWumFK for ; Fri, 8 Jul 2016 17:45:53 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0126.outbound.protection.outlook.com [23.103.200.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D6912B040 for ; Fri, 8 Jul 2016 17:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lihC5fZyBNWSRjhst7u8ifuulVg3fZf956vfS+R3Q1Y=; b=qIuQfzDUYoDpr70dRHd+xC195Icoo0F1DsIjEISRRzQzFzwg7ZseGVv9R7t23KsTWDRLZ6qWeBiawKh/Rf0QwdxqG+h2oQkfF3I96ca0XeTwMNhTi1N4gnx5ApF/w3FCvLCheTv+0Xwq/hSYkJrs7JJOrRzkpeZ/NARdVZ/GC9s= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) with Microsoft SMTP Server (TLS) id 15.1.534.14; Sat, 9 Jul 2016 00:45:51 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0534.020; Sat, 9 Jul 2016 00:45:51 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-ietf-idr-route-leak-detection-mitigation-04.txt Thread-Index: AQHR2WCrrrbulJtx4EiHTxiW5uF0mKAO+eVj Date: Sat, 9 Jul 2016 00:45:51 +0000 Message-ID: References: <20160708213534.32176.45760.idtracker@ietfa.amsl.com> In-Reply-To: <20160708213534.32176.45760.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.219.4] x-ms-office365-filtering-correlation-id: 21e7e9d2-4b68-4b0c-2565-08d3a79260b9 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0446; 6:Ufnw5J/4L5/9GEH2Dqyku/9rG+jvDX6JlO4VlKK1gl1+RaezBMTSEybOIiWb4LL7m9MVVDDLfceikZsLlReZEgq4dW/fDO9ZOySjThA+nIK8tTlH8faJjpHmYLwNccMTXj4mJEvjq7UjaYdCVYYJQqNUc3ta2KQN2NgIz/ZfpYi+heUYA2r2vdSwwRPNvWUY7f5aloxhAGKV9nbw2q+7ZP8k3NFFUJfEqjSkul4+0LrnBqrMcr3TodNhBlxSn46rsM8cdDr7Z40gdteWWu43bdFXTm9EiDChJKENMu5SyNRLSvVOLyIPmFeSO6Am7mRLmOD//5rmrC6EhOgsQ3tB+g==; 5:ppy7ONDYJoYBA0Du29kyxWASktI9t1vyLdpV3olCNAZkNLnhwIAL2v2EFN9KmnEDdRoGiQjI0o4Pxt7BUS2hk0Q9ojlNov5gUKIQE7V/qLiBJQKfYDa5BW35W0YZBHBxW2aECENJIxh6PhBrWMjzPg==; 24:ZbNT7fOq0n1bf0CWbZ2j9U7jx9Dj03iyiJLtaEC/1DoAiSwQJ0c5cWldPagkntIhEsLT1VUcMnS2ffNzcz+vFht+cXgMZhlE2YBvgQ6TCDE=; 7:kzO7TjfwXgXvizA1oKCuRviYXkXDnBmP2WVRoSITABepx4HAQ63f6x8pRQBZscdElhaqwsX8ZUih8mE/r1WeqRL3z/Tufyrxi7VnuGnrA6k8XBTKCO0pRk/7JZpwrGN6QIT7QPCrzgQEvLpdIJ9JcQedRev3fj0EyYfnwhclX+Sb+TnODg5ahegZV6uh5ggbazw3AYHcN0mJGDMU1A/VHlUBPlkBA2WCOFtWfm5IhROKkwbP+UnPeUjXl6tEUZyS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM2PR09MB0446; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0446; x-forefront-prvs: 0998671D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(199003)(377424004)(106356001)(10400500002)(106116001)(97736004)(15650500001)(76576001)(2900100001)(3280700002)(189998001)(66066001)(105586002)(86362001)(9686002)(8936002)(33656002)(2351001)(7736002)(7696003)(3846002)(99286002)(87936001)(50986999)(3660700001)(101416001)(305945005)(2906002)(6116002)(102836003)(7846002)(68736007)(5003600100003)(54356999)(586003)(5002640100001)(92566002)(450100001)(74316002)(122556002)(76176999)(15975445007)(19580405001)(77096005)(19580395003)(230783001)(2501003)(1730700003)(107886002)(3900700001)(110136002)(81166006)(5640700001)(8676002)(2950100001)(11100500001)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0446; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2016 00:45:51.4338 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0446 Archived-At: Subject: [Idr] Fw: New Version Notification for draft-ietf-idr-route-leak-detection-mitigation-04.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: Sat, 09 Jul 2016 00:45:56 -0000 Minor updates done in this new version: 1. Added a reference to the discussions from the NANOG list in June 2016 which provide support for the material on "Intra-AS Messaging for Route Le= ak Prevention" in Section 3.2. 2. The last paragraph in Section 4 is new.=20 This paragraph actually belongs more suitably at the end of Section 5.4. W= ill make that move in the next revision. Sriram ________________________________________ From: internet-drafts@ietf.org Sent: Friday, July 8, 2016 5:35 PM To: Brian Dickson; Montgomery, Douglas (Fed); Keyur Patel; Andrei Robachevs= ky; Sriram, Kotikalapudi (Fed) Subject: New Version Notification for draft-ietf-idr-route-leak-detection-m= itigation-04.txt A new version of I-D, draft-ietf-idr-route-leak-detection-mitigation-04.txt has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository. Name: draft-ietf-idr-route-leak-detection-mitigation Revision: 04 Title: Methods for Detection and Mitigation of BGP Route Leaks Document date: 2016-07-08 Group: idr Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-ietf-idr-route-l= eak-detection-mitigation-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-= detection-mitigation/ Htmlized: https://tools.ietf.org/html/draft-ietf-idr-route-leak-detec= tion-mitigation-04 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-route-le= ak-detection-mitigation-04 Abstract: [I-D.ietf-grow-route-leak-problem-definition] provides a definition of the route leak problem, and also enumerates several types of route leaks. This document first examines which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811]. It is recognized that OV offers a limited detection and mitigation capability against route leaks. This document specifies enhancements that significantly extend the route-leak prevention, detection, and mitigation capabilities of BGP. One solution component involves carrying a per-hop route-leak protection (RLP) field in BGP updates. The RLP field is proposed be carried in a new optional transitive attribute, called BGP RLP attribute. The solution is meant to be initially implemented as an enhancement of BGP without requiring BGPsec [I-D.ietf-sidr-bgpsec-protocol]. However, when BGPsec is deployed in the future, the solution can be incorporated in BGPsec, enabling cryptographic protection for the RLP field. That would be one way of implementing the proposed solution in a secure way. The document also includes a stopgap method for detection and mitigation of route leaks for an intermediate phase when OV is deployed but BGP protocol on the wire is unchanged. From nobody Sat Jul 9 12:49:19 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 CC52812D0D3 for ; Sat, 9 Jul 2016 12:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[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 RQ_eJrHVeOQ8 for ; Sat, 9 Jul 2016 12:49:15 -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 5383E12B05A for ; Sat, 9 Jul 2016 12:49:15 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id h129so47033116lfh.1 for ; Sat, 09 Jul 2016 12:49:15 -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=WeheELEK4ZxgzNo6e9/yblrwmZtSnLBXJAvg8JjZPTI=; b=H9XyhEufWNcwX54DfgRSwY5tssrvsmbYWOCYUwvzcl0z/FcOc+Y6ktfvy27mOWQ1vm bg7b1iU6t6Nvy0d6D1si4HemT+7xbi022n3ljP9aU2fv+IY+z4yWCd+owcXbT6388UbF hFISByZ/5eyNJT1o/sWZl7T1EgmHKR+4w2ZMT9TzpcHmOSnfYdozlzUrgz5tWbP1cVOp Q2kmtEC6jJjKvMcvs/+GZy/jgs2H3PYvz1Dvz0SpJs1yd2y7aGVuMEL2BaMnC98bwbRc +wS7T8v6Q9rxTalTWdjWwqG2DZEwhM/l163OaTBy5yy/rkRo2zDjiq8nnP4lzKL9qYy7 yzwA== 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=WeheELEK4ZxgzNo6e9/yblrwmZtSnLBXJAvg8JjZPTI=; b=Jlp7mGFWFWmbUGlcpxzZ4Tp99joBJodMkYjW+62MmitF2hpNEFFwi7R2G5zl3+wutf vZmp7DnSW4lnlZ327+K2FXKdt/K2ohSm8tOn7BUtIzEHOostYhvuomItTDTojZV/eipI e3T2JUbM3sCSsJ6VRu2JOneAqyBfiVXaPhYNtZiHQrgYDOERjCX2ay15XAQF2BbvFs/G UrbAC1bvLOdU8TGPDLkVTLQL62odNAJ+vbCjoBnemLslZjeyegjoSKX8PoFAwOazFH1A 4bOglkdaR/fb2GdaY0IOzZ5vSmpW39HSACx3mu1korvsBdaaEckxFKhpyUok0MjVzHmQ JIvg== X-Gm-Message-State: ALyK8tIwFH7UfYZBanhvzL1ICNb9Pek25yiWzXO4RuEmxdJUAUhmX1EoemmiBakQvijX+JKiVi4fFXmzMaqBBQ== X-Received: by 10.25.214.97 with SMTP id n94mr3217246lfg.105.1468093753286; Sat, 09 Jul 2016 12:49:13 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.18.225 with HTTP; Sat, 9 Jul 2016 12:49:12 -0700 (PDT) In-Reply-To: References: From: Robert Raszuk Date: Sat, 9 Jul 2016 21:49:12 +0200 X-Google-Sender-Auth: nKwMP1NapIVFFq-cqu0nBme_-fc Message-ID: To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a1140ef7aa9662a05373936ac Archived-At: Cc: "Keyur Patel $keyupate$" , "Derek Man-Kit Yeung $myeung$" , idr wg Subject: Re: [Idr] Shortest Path Routing Extensions for BGP Protocol 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: