From nobody Tue Apr 1 07:45:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49AB1A086E; Tue, 1 Apr 2014 07:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1a2cSOnMeiWu; Tue, 1 Apr 2014 07:44:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A94491A0858; Tue, 1 Apr 2014 07:44:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401144458.19320.58396.idtracker@ietfa.amsl.com> Date: Tue, 01 Apr 2014 07:44:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/9DOTS0XmRxoP1-hU3E1MbWSypm0 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-redirect-rt-bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 14:45:00 -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 Working Group of the IETF. Title : Clarification of the Flowspec Redirect Extended Community Author : Jeffrey Haas Filename : draft-ietf-idr-flowspec-redirect-rt-bis-00.txt Pages : 6 Date : 2014-04-01 Abstract: This document clarifies the formatting of the the BGP Flowspec Redirect Extended Community, originally documented in RFC 5575. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-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 Apr 4 12:47:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F411A01CC for ; Fri, 4 Apr 2014 12:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 dtZgmMeAjPgd for ; Fri, 4 Apr 2014 12:47:32 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8A1A045A for ; Fri, 4 Apr 2014 12:46:04 -0700 (PDT) Received: from mail222-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Fri, 4 Apr 2014 19:45:55 +0000 Received: from mail222-tx2 (localhost [127.0.0.1]) by mail222-tx2-R.bigfish.com (Postfix) with ESMTP id E5430540138 for ; Fri, 4 Apr 2014 19:45:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzc85fhzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz18c673hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail222-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=pmattes@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(59766001)(87266001)(15202345003)(77982001)(2656002)(85852003)(76482001)(92566001)(56776001)(74366001)(87936001)(69226001)(83072002)(97186001)(47446002)(74502001)(79102001)(46102001)(93516002)(15975445006)(74662001)(4396001)(50986001)(47976001)(47736001)(49866001)(81816001)(31966008)(99396002)(81686001)(99286001)(54356001)(74706001)(53806001)(20776003)(80976001)(93136001)(74876001)(81342001)(81542001)(51856001)(85306002)(63696002)(19580395003)(76576001)(76786001)(76796001)(95416001)(76176001)(97336001)(74316001)(66066001)(56816005)(90146001)(54316002)(80022001)(65816001)(95666003)(33646001)(77096001)(94946001)(86362001)(94316002)(98676001)(83322001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB162; H:BL2PR05MB161.namprd05.prod.outlook.com; FPR:FE14F11A.8FFAD989.B9DD6197.1508CD01.208E4; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail222-tx2 (localhost.localdomain [127.0.0.1]) by mail222-tx2 (MessageSwitch) id 1396640753981665_32647; Fri, 4 Apr 2014 19:45:53 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.228]) by mail222-tx2.bigfish.com (Postfix) with ESMTP id EA7911C0061 for ; Fri, 4 Apr 2014 19:45:53 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 4 Apr 2014 19:45:54 +0000 Received: from BL2PR05MB162.namprd05.prod.outlook.com (10.242.198.19) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 4 Apr 2014 19:45:57 +0000 Received: from BL2PR05MB161.namprd05.prod.outlook.com (10.242.198.13) by BL2PR05MB162.namprd05.prod.outlook.com (10.242.198.19) with Microsoft SMTP Server (TLS) id 15.0.913.9; Fri, 4 Apr 2014 19:45:56 +0000 Received: from BL2PR05MB161.namprd05.prod.outlook.com ([169.254.12.68]) by BL2PR05MB161.namprd05.prod.outlook.com ([169.254.12.68]) with mapi id 15.00.0913.002; Fri, 4 Apr 2014 19:45:56 +0000 From: Paul Mattes To: "idr@ietf.org" Thread-Topic: Possible weakness in long-lived graceful restart Thread-Index: Ac9QO9JE+CyeW2xWRcmYZ+xCsyyfPw== Date: Fri, 4 Apr 2014 19:45:55 +0000 Message-ID: <2f22313a3a5c4c278e5517aca8463dba@BL2PR05MB161.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 01713B2841 Content-Type: multipart/alternative; boundary="_000_2f22313a3a5c4c278e5517aca8463dbaBL2PR05MB161namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ekXeNNVGZmY0fr02EEFj4HvRi2A Subject: [Idr] Possible weakness in long-lived graceful restart X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 19:47:37 -0000 --_000_2f22313a3a5c4c278e5517aca8463dbaBL2PR05MB161namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been doing some work on long-lived graceful restart (LLGR) and a pla= usible failure scenario has come up in discussions here, which does not app= ear to be covered, though it certainly seems to be the sort of failure that= should be addressed by LLGR. The scenario happens when we have LLGR configured on both sides of a number= of peering sessions, and BGP speaker (e.g., a Route Reflector) loses conta= ct with a number of its peers simultaneously. The likely cause would be tha= t the paths to the peers share a common element that has failed. (And note = that the common element could be part of the BGP speaker in question - some= thing that can be repaired without restarting the system.) When contact with this set of peers is re-established, the scenario has man= y of the same semantics of a restart. In particular, it would be best to de= lay sending End-of-RIB indications to any of the members of this set of pee= rs until End-Of-RIB to any of them, or until a reasonable timeout expires a= fter the first comes back. Without this delay, the one BGP speaker would li= kely send each of the peers a large number of advertisements with the LLGR_= STALE attribute (for the stale routes held for the other disconnected peers= ), followed by a large number of advertisements of the those same routes wi= thout the LLGR_STALE attribute (as those routes are refreshed by the other = peers). There would likely be no change in reachability throughout the netw= ork, but there could be a significant amount of FIB thrashing and transient= spikes in forwarding traffic, as well as a significant BGP-related I/O and= processing load on each of the speakers. While it seems like a restart, it is of course not a restart. And as far as= the peers which remain connected are concerned, it does not appear anythin= g like a restart at all. While it is possible to imagine an implementation of LLGR that addresses th= is issue outside of the specification, I think it would be best if the spec= ification handled this scenario better, whether through a change in the pro= tocol or additional implementation advice. -- pdm --_000_2f22313a3a5c4c278e5517aca8463dbaBL2PR05MB161namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have been doing some work on long-lived graceful restart (LLGR) and = a plausible failure scenario has come up in discussions here, which does no= t appear to be covered, though it certainly seems to be the sort of failure= that should be addressed by LLGR.
 
The scenario happens when we have LLGR configured on both sides of a n= umber of peering sessions, and BGP speaker (e.g., a Route Reflector) loses = contact with a number of its peers simultaneously. The likely cause would b= e that the paths to the peers share a common element that has failed. (And note that the common element could b= e part of the BGP speaker in question – something that can be repaire= d without restarting the system.)
 
When contact with this set of peers is re-established, the scenario ha= s many of the same semantics of a restart. In particular, it would be best = to delay sending End-of-RIB indications to any of the members of this set o= f peers until End-Of-RIB to any of them, or until a reasonable timeout expires after the first comes back. = Without this delay, the one BGP speaker would likely send each of the peers= a large number of advertisements with the LLGR_STALE attribute (for the st= ale routes held for the other disconnected peers), followed by a large number of advertisements of the those same rout= es without the LLGR_STALE attribute (as those routes are refreshed by the o= ther peers). There would likely be no change in reachability throughout the= network, but there could be a significant amount of FIB thrashing and transient spikes in forwarding traffic, as well= as a significant BGP-related I/O and processing load on each of the speake= rs.
 
While it seems like a restart, it is of course not a restart. And as f= ar as the peers which remain connected are concerned, it does not appear an= ything like a restart at all.
 
While it is possible to imagine an implementation of LLGR that address= es this issue outside of the specification, I think it would be best if the= specification handled this scenario better, whether through a change in th= e protocol or additional implementation advice.
 
--
        pdm
 
 
 
 --_000_2f22313a3a5c4c278e5517aca8463dbaBL2PR05MB161namprd05pro_-- From nobody Fri Apr 4 13:32:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4061A010B for ; Fri, 4 Apr 2014 13:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=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 iJNPVTeJH383 for ; Fri, 4 Apr 2014 13:32:27 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB6A1A0238 for ; Fri, 4 Apr 2014 13:32:25 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id hn18so1419334igb.17 for ; Fri, 04 Apr 2014 13:32:20 -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:date:message-id:subject :from:to:cc:content-type; bh=WUx5fQbDGnvWBSTuLwiSCvUs5nbCxD8jWaq/LvdyE6c=; b=zhppdzijxRB/uZaA1wx01CJ77pfmVXsKBwqYBWNfB2zBHG3ZGYAewdDc4aZAYYCNOo vFsnYvnmFdhWlB2bQbEP35b/oB9k298pDGgkFFHUipO31S8FMFDEpZtGkE6drA/kEFNH MypBdPGOVjeBm2Gt9lcUjmzyN6xxiZQfo7uRLz20gX7yaxSjADFeKlpyOChJV0vRuk7C VlrpXwBVFm0PkKatqShpt/22nl04EXV4GmvGO/y9NiO8PMN6MuTEOdFe8GeXZe1YSd1E qaEZ1YeHbZP3hNUQ9Y+Yc0YWKdTHfnKWN04qEblYTziqZexOVtbU6WslJr3hK3vPl33L pc6g== MIME-Version: 1.0 X-Received: by 10.43.4.2 with SMTP id oa2mr14202863icb.4.1396643540385; Fri, 04 Apr 2014 13:32:20 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 4 Apr 2014 13:32:20 -0700 (PDT) In-Reply-To: <2f22313a3a5c4c278e5517aca8463dba@BL2PR05MB161.namprd05.prod.outlook.com> References: <2f22313a3a5c4c278e5517aca8463dba@BL2PR05MB161.namprd05.prod.outlook.com> Date: Fri, 4 Apr 2014 22:32:20 +0200 X-Google-Sender-Auth: EMqFXsQK2cc2QQcC0MxRZs4-1j4 Message-ID: From: Robert Raszuk To: Paul Mattes Content-Type: multipart/alternative; boundary=bcaec5014cbd1a472f04f63d6a3b Archived-At: http://mailarchive.ietf.org/arch/msg/idr/L_Nx19JH9XDjogOA3ez7agJXenI Cc: "idr@ietf.org" Subject: Re: [Idr] Possible weakness in long-lived graceful restart X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:32:31 -0000 --bcaec5014cbd1a472f04f63d6a3b Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, I think your observation is valid and possible in real deployments however the fix you are asking for may be slightly. First let's observe that "Restart Time" and "Long lived Stale Time" is per session and defined procedures are also per session. To apply any solution it would be required to find a way to dynamically group peers which may belong to the same "peer failure risk group", but that is hard as IBGP sessions to those peers naturally are designed to work around single network failures. An option could be perhaps to treat all peers running in under "Long lived Stale Time" state as one group and then define a "Long Lived Read Only Timer" which would start from the first session previously in such group to get re-established and till it expires suppress any best path computation based on the newly received paths from those peers. Literally what you are pointing out could be fixed by the following text addition to "draft-uttaro-idr-bgp-persistence-03" section 4.2: Current text: Once the session is re-established, the procedures specified in [RFC4724] apply for the stale routes irrespective of whether the stale routes are retained during the"Restart Time" period or the "Long-lived Stale Time" period. However, in the case of consecutive restarts (i.e,the session goes down before the EoR is received) the previously marked stale routes MUST NOT be deleted before the timer for the "Long-lived Stale Time" expires. New text: All sessions in "Long-lived Stale Time" are grouped into "Long-lived Sessions Group". New timer called "Long-lived Session Read Only Timer" is defined. Once the session is re-established, the procedures specified in [RFC4724] apply for the stale routes irrespective of whether the stale routes are retained during the"Restart Time" period or the "Long-lived Stale Time" period except that such procedures are delayed for the peers belonging to "Long-lived Sessions Group" till all members of the group send EOR message or the "Long-lived Session Read Only Timer" expires. The "Long-lived Session Read Only Timer" is started upon reestablishment ofthe first session belonging to "Long-lived Sessions Group". However, in the case of consecutive restarts (i.e, the session goes down before the EoR is received) the previously marked stale routes MUST NOT be deleted before the timer for the "Long-lived Stale Time" expires. Best regards, R. On Fri, Apr 4, 2014 at 9:45 PM, Paul Mattes wrote: > I have been doing some work on long-lived graceful restart (LLGR) and a > plausible failure scenario has come up in discussions here, which does not > appear to be covered, though it certainly seems to be the sort of failure > that should be addressed by LLGR. > > The scenario happens when we have LLGR configured on both sides of a > number of peering sessions, and BGP speaker (e.g., a Route Reflector) loses > contact with a number of its peers simultaneously. The likely cause would > be that the paths to the peers share a common element that has failed. (And > note that the common element could be part of the BGP speaker in question - > something that can be repaired without restarting the system.) > > When contact with this set of peers is re-established, the scenario has > many of the same semantics of a restart. In particular, it would be best to > delay sending End-of-RIB indications to any of the members of this set of > peers until End-Of-RIB to any of them, or until a reasonable timeout > expires after the first comes back. Without this delay, the one BGP speaker > would likely send each of the peers a large number of advertisements with > the LLGR_STALE attribute (for the stale routes held for the other > disconnected peers), followed by a large number of advertisements of the > those same routes without the LLGR_STALE attribute (as those routes are > refreshed by the other peers). There would likely be no change in > reachability throughout the network, but there could be a significant > amount of FIB thrashing and transient spikes in forwarding traffic, as well > as a significant BGP-related I/O and processing load on each of the > speakers. > > While it seems like a restart, it is of course not a restart. And as far > as the peers which remain connected are concerned, it does not appear > anything like a restart at all. > > While it is possible to imagine an implementation of LLGR that addresses > this issue outside of the specification, I think it would be best if the > specification handled this scenario better, whether through a change in the > protocol or additional implementation advice. > > -- > *pdm* > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --bcaec5014cbd1a472f04f63d6a3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paul,

I think your observation is valid and = possible in real deployments however the fix you are asking for may be slig= htly. 

First let&= #39;s observe that "Restart Time" and "Long lived Stale Time= " is per session and defined procedures are also per session. 

To apply any solution it would be required to find a way to dynamically = group peers which may belong to the same "peer failure risk group"= ;, but that is hard as IBGP sessions to those peers naturally are designed = to work around single network failures. 

An option = could be perhaps to treat all peers running in under "Long lived Stale= Time" state as one group and then define a "Long Lived Read Only= Timer" which would start from the first session previously in such gr= oup to get re-established and till it expires suppress any best path comput= ation based on the newly received paths from those peers. 

Literally = what you are pointing out could be fixed by the following text addition to = "draft-uttaro-idr-bgp-persistence-03" section 4.2: 

Current te= xt:

Once the session is re-establis=
hed, the procedures specified in [RFC4724] apply for the stale routes irres=
pective of whether the stale routes are retained during the"Restart Ti=
me" period or the "Long-lived Stale Time" period. 
However, in the case of consecutive restarts (i.e,the session goes down before the =
EoR is received) the previously marked stale routes MUST NOT be=
 deleted before the timer for the "Long-lived Stale Time" expires=
.

New = text:

All sessio= ns in "Long-lived Stale Time" are grouped into "Long-lived S= essions Group". New timer called "Long-lived Session Read Only Ti= mer" is defined. 

Once the session is re-establis=
hed, the procedures specified in [RFC4724] 
apply for the stale routes irre=
spective of whether the stale routes are retained during the"Restart T=
ime" period or the "Long-lived Stale Time" period except tha=
t such procedures are delayed for the peers belonging to "Long-live=
d 
Sessions Gro=
up" till all members of the group send EOR message or the =

"Lon=
g-lived Session Read Only Timer" expires. 

The "Long-lived Session Read Only Timer" is started upon re=
establishment ofthe first session belonging to "Long-lived Sessions=
 Group".

<=
/span>
However, in the c=
ase of consecutive restarts (i.e, the session goes down 


before the EoR is received) the previous=
ly marked stale routes MUST NOT 
be deleted before the timer for=
 the "Long-lived Stale Time" expires.


Best regards,
R.



On Fri, Apr 4, 20= 14 at 9:45 PM, Paul Mattes <pmattes@juniper.net> wrote:
I have been doing some work on long-lived graceful restart (LLGR) and = a plausible failure scenario has come up in discussions here, which does no= t appear to be covered, though it certainly seems to be the sort of failure= that should be addressed by LLGR.
 
The scenario happens when we have LLGR configured on both sides of a n= umber of peering sessions, and BGP speaker (e.g., a Route Reflector) loses = contact with a number of its peers simultaneously. The likely cause would b= e that the paths to the peers share a common element that has failed. (And note that the common element could b= e part of the BGP speaker in question – something that can be repaire= d without restarting the system.)
 
When contact with this set of peers is re-established, the scenario ha= s many of the same semantics of a restart. In particular, it would be best = to delay sending End-of-RIB indications to any of the members of this set o= f peers until End-Of-RIB to any of them, or until a reasonable timeout expires after the first comes back. = Without this delay, the one BGP speaker would likely send each of the peers= a large number of advertisements with the LLGR_STALE attribute (for the st= ale routes held for the other disconnected peers), followed by a large number of advertisements of the those same rout= es without the LLGR_STALE attribute (as those routes are refreshed by the o= ther peers). There would likely be no change in reachability throughout the= network, but there could be a significant amount of FIB thrashing and transient spikes in forwarding traffic, as well= as a significant BGP-related I/O and processing load on each of the speake= rs.
 
While it seems like a restart, it is of course not a restart. And as f= ar as the peers which remain connected are concerned, it does not appear an= ything like a restart at all.
 
While it is possible to imagine an implementation of LLGR that address= es this issue outside of the specification, I think it would be best if the= specification handled this scenario better, whether through a change in th= e protocol or additional implementation advice.
 
--
        pdm
 
 
 

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


--bcaec5014cbd1a472f04f63d6a3b-- From nobody Fri Apr 4 15:26:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6E11A0184 for ; Fri, 4 Apr 2014 15:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 R_d6jSSxtjQa for ; Fri, 4 Apr 2014 15:26:11 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id CD0B61A012E for ; Fri, 4 Apr 2014 15:26:10 -0700 (PDT) Received: from mail130-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.22; Fri, 4 Apr 2014 22:26:00 +0000 Received: from mail130-va3 (localhost [127.0.0.1]) by mail130-va3-R.bigfish.com (Postfix) with ESMTP id 7D1313800EC; Fri, 4 Apr 2014 22:26:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz98dI9371Ic85fhzz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail130-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=pmattes@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(24454002)(189002)(199002)(377454003)(4396001)(74316001)(15202345003)(49866001)(47736001)(47976001)(50986001)(83072002)(85852003)(46102001)(79102001)(54356001)(74706001)(53806001)(51856001)(74366001)(66066001)(80022001)(20776003)(63696002)(65816001)(33646001)(81686001)(81816001)(80976001)(16236675002)(15975445006)(94946001)(94316002)(93136001)(19609705001)(92566001)(93516002)(86362001)(87266001)(81342001)(87936001)(97186001)(19300405004)(2656002)(81542001)(95666003)(85306002)(90146001)(76786001)(76576001)(74502001)(97336001)(31966008)(47446002)(19580405001)(19580395003)(76796001)(56816005)(74662001)(74876001)(99286001)(95416001)(98676001)(77096001)(83322001)(59766001)(56776001)(76482001)(77982001)(54316002)(69226001)(99396002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB163; H:BL2PR05MB161.namprd05.prod.outlook.com; FPR:AEF6F119.ACFA5C11.73D73173.4EF9D040.205A8; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail130-va3 (localhost.localdomain [127.0.0.1]) by mail130-va3 (MessageSwitch) id 139665035837005_4976; Fri, 4 Apr 2014 22:25:58 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.249]) by mail130-va3.bigfish.com (Postfix) with ESMTP id ED9AD3600F4; Fri, 4 Apr 2014 22:25:57 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 4 Apr 2014 22:26:00 +0000 Received: from BL2PR05MB163.namprd05.prod.outlook.com (10.242.198.26) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 4 Apr 2014 22:26:01 +0000 Received: from BL2PR05MB161.namprd05.prod.outlook.com (10.242.198.13) by BL2PR05MB163.namprd05.prod.outlook.com (10.242.198.26) with Microsoft SMTP Server (TLS) id 15.0.913.9; Fri, 4 Apr 2014 22:26:01 +0000 Received: from BL2PR05MB161.namprd05.prod.outlook.com ([169.254.12.68]) by BL2PR05MB161.namprd05.prod.outlook.com ([169.254.12.68]) with mapi id 15.00.0913.002; Fri, 4 Apr 2014 22:26:00 +0000 From: Paul Mattes To: Robert Raszuk Thread-Topic: [Idr] Possible weakness in long-lived graceful restart Thread-Index: Ac9QO9JE+CyeW2xWRcmYZ+xCsyyfPwACSfEAAAMMYZA= Date: Fri, 4 Apr 2014 22:26:00 +0000 Message-ID: <458f7a3d7c32425f99bac4cc0608d30c@BL2PR05MB161.namprd05.prod.outlook.com> References: <2f22313a3a5c4c278e5517aca8463dba@BL2PR05MB161.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 01713B2841 Content-Type: multipart/alternative; boundary="_000_458f7a3d7c32425f99bac4cc0608d30cBL2PR05MB161namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/idr/mjcfoLf80jqS3r_EXbs9gqXHGNE Cc: "idr@ietf.org" Subject: Re: [Idr] Possible weakness in long-lived graceful restart X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 22:26:18 -0000 --_000_458f7a3d7c32425f99bac4cc0608d30cBL2PR05MB161namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that my original suggestion of just suppressing End-of-RIB wouldn't= help much with the thrashing. So this appears less like a partial-restart = scenario than I had thought. I see that your solution could avoid a lot thrashing. The router implementi= ng this procedure would still initially advertise its stale RIB (some route= s LLGR-stale, some not) to each of the newly-re-established peers, and send= End-of-RIB. The new timer would prevent it from advertising intermediate s= tates for routes from the group, until each of the peers has sent End-of-RI= B. Then it would re-advertise whichever routes are now best, looking like s= omething close to the last state they were advertised in before the disaste= r. The worst case for this is advertising every route from the group twice,= which is much better than the existing worst case, which is (I think) adve= rtising every route N times, where N is the number of peers that disconnect= ed. But the best case, and I think the typical case with the read-only timer, w= ould also be double advertisements of each route - once with LLGR_STALE att= ached, and once without it. Can we do better still? My hope is to avoid sending out that first wave of = LLGR_STALE routes, too, if we can. Or am I misunderstanding how your mechan= ism would work? -- pdm From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Friday, April 04, 2014 3:32 PM To: Paul Mattes Cc: idr@ietf.org Subject: Re: [Idr] Possible weakness in long-lived graceful restart Hi Paul, I think your observation is valid and possible in real deployments however = the fix you are asking for may be slightly. First let's observe that "Restart Time" and "Long lived Stale Time" is per = session and defined procedures are also per session. To apply any solution it would be required to find a way to dynamically gro= up peers which may belong to the same "peer failure risk group", but that i= s hard as IBGP sessions to those peers naturally are designed to work aroun= d single network failures. An option could be perhaps to treat all peers running in under "Long lived = Stale Time" state as one group and then define a "Long Lived Read Only Time= r" which would start from the first session previously in such group to get= re-established and till it expires suppress any best path computation base= d on the newly received paths from those peers. Literally what you are pointing out could be fixed by the following text ad= dition to "draft-uttaro-idr-bgp-persistence-03" section 4.2: Current text: Once the session is re-established, the procedures specified in [RFC4724] a= pply for the stale routes irrespective of whether the stale routes are reta= ined during the"Restart Time" period or the "Long-lived Stale Time" period. However, in the case of consecutive restarts (i.e,the session goes down bef= ore the EoR is received) the previously marked stale routes MUST NOT be del= eted before the timer for the "Long-lived Stale Time" expires. New text: All sessions in "Long-lived Stale Time" are grouped into "Long-lived Sessio= ns Group". New timer called "Long-lived Session Read Only Timer" is defined= . Once the session is re-established, the procedures specified in [RFC4724] apply for the stale routes irrespective of whether the stale routes are ret= ained during the"Restart Time" period or the "Long-lived Stale Time" period= except that such procedures are delayed for the peers belonging to "Long-l= ived Sessions Group" till all members of the group send EOR message or the "Long-lived Session Read Only Timer" expires. The "Long-lived Session Read Only Timer" is started upon reestablishment of= the first session belonging to "Long-lived Sessions Group". However, in the case of consecutive restarts (i.e, the session goes down before the EoR is received) the previously marked stale routes MUST NOT be deleted before the timer for the "Long-lived Stale Time" expires. Best regards, R. On Fri, Apr 4, 2014 at 9:45 PM, Paul Mattes > wrote: I have been doing some work on long-lived graceful restart (LLGR) and a pla= usible failure scenario has come up in discussions here, which does not app= ear to be covered, though it certainly seems to be the sort of failure that= should be addressed by LLGR. The scenario happens when we have LLGR configured on both sides of a number= of peering sessions, and BGP speaker (e.g., a Route Reflector) loses conta= ct with a number of its peers simultaneously. The likely cause would be tha= t the paths to the peers share a common element that has failed. (And note = that the common element could be part of the BGP speaker in question - some= thing that can be repaired without restarting the system.) When contact with this set of peers is re-established, the scenario has man= y of the same semantics of a restart. In particular, it would be best to de= lay sending End-of-RIB indications to any of the members of this set of pee= rs until End-Of-RIB to any of them, or until a reasonable timeout expires a= fter the first comes back. Without this delay, the one BGP speaker would li= kely send each of the peers a large number of advertisements with the LLGR_= STALE attribute (for the stale routes held for the other disconnected peers= ), followed by a large number of advertisements of the those same routes wi= thout the LLGR_STALE attribute (as those routes are refreshed by the other = peers). There would likely be no change in reachability throughout the netw= ork, but there could be a significant amount of FIB thrashing and transient= spikes in forwarding traffic, as well as a significant BGP-related I/O and= processing load on each of the speakers. While it seems like a restart, it is of course not a restart. And as far as= the peers which remain connected are concerned, it does not appear anythin= g like a restart at all. While it is possible to imagine an implementation of LLGR that addresses th= is issue outside of the specification, I think it would be best if the spec= ification handled this scenario better, whether through a change in the pro= tocol or additional implementation advice. -- pdm _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_458f7a3d7c32425f99bac4cc0608d30cBL2PR05MB161namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that my original = suggestion of just suppressing End-of-RIB wouldn’t help much with the= thrashing. So this appears less like a partial-restart scenario than I had thought.

 <= /p>

I see that your solution = could avoid a lot thrashing. The router implementing this procedure would s= till initially advertise its stale RIB (some routes LLGR-stale, some not) to each of the newly-re-established peers, and send End-of-RIB. = The new timer would prevent it from advertising intermediate states for rou= tes from the group, until each of the peers has sent End-of-RIB. Then it wo= uld re-advertise whichever routes are now best, looking like something close to the last state they were adv= ertised in before the disaster. The worst case for this is advertising ever= y route from the group twice, which is much better than the existing worst = case, which is (I think) advertising every route N times, where N is the number of peers that disconnected.

 <= /p>

But the best case, and I = think the typical case with the read-only timer, would also be double adver= tisements of each route – once with LLGR_STALE attached, and once without it.

 <= /p>

Can we do better still? M= y hope is to avoid sending out that first wave of LLGR_STALE routes, too, i= f we can. Or am I misunderstanding how your mechanism would work?

 <= /p>

--

    &= nbsp;   pdm

 <= /p>

From: rraszu= k@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, April 04, 2014 3:32 PM
To: Paul Mattes
Cc: idr@ietf.org
Subject: Re: [Idr] Possible weakness in long-lived graceful restart<= o:p>

 

Hi Paul,

 

I think your observation is valid and possible in real dep= loyments however the fix you are asking for may be slightly. 

 

First let's observe that "Restart Time" and &quo= t;Long lived Stale Time" is per session and defined procedures are als= o per session. 

 

To apply any solution it would be required to find a way t= o dynamically group peers which may belong to the same "peer failure r= isk group", but that is hard as IBGP sessions to those peers naturally are designed to work around single network failures. 

 

An option could be perhaps to treat all peers running in u= nder "Long lived Stale Time" state as one group and then define a= "Long Lived Read Only Timer" which would start from the first se= ssion previously in such group to get re-established and till it expires suppres= s any best path computation based on the newly received paths from those pe= ers. 

 

Literally what you are pointing out could be fixed by the = following text addition to "draft-uttaro-idr-bgp-persistence-03" = section 4.2: 

 

Current text:

 

 
Once the session is re-established,=
 the procedures specified in [RFC4724] apply for the stale routes irrespect=
ive of whether the stale routes are retained during the"Restart Time&q=
uot; period or the "Long-lived Stale Time" period. 
However, in the case of consecutive=
 restarts (i.e,the session goes down before the EoR is received) the previo=
usly marked stale routes MUST NOT be deleted before the timer for the "=
;Long-lived Stale Time" expires.

 

New text:

 

All sessions in "Long-lived Stale Time" are grou= ped into "Long-lived Sessions Group". New timer called "Long= -lived Session Read Only Timer" is defined. 

 

 
Once the session is re-established,=
 the procedures specified in [RFC4724] 
 
apply for the stale routes irrespec=
tive of whether the stale routes are retained during the"Restart Time&=
quot; period or the "Long-lived Stale Time" period except that su=
ch procedures are delayed for the peers belonging to "Long-lived 
Sessions Group&q=
uot; till all members of the group send EOR message or the 
"Long-lived=
 Session Read Only Timer" expires. 
 
 
The "Long-lived Session Read Only Timer" is started upon reestablish=
ment ofthe first session belonging to "Long-lived Sessions Group"=
.
 
However, in the case of consecutive=
 restarts (i.e, the session goes down 
 
before the EoR is received) the pre=
viously marked stale routes MUST NOT 
 
be deleted before the timer for the=
 "Long-lived Stale Time" expires.
 
 
 
 
 
Best regards,
R.


 

 

On Fri, Apr 4, 2014 at 9:45 PM, Paul Mattes <pmattes@juniper.net> wrote:

I have been doing some work on long-liv= ed graceful restart (LLGR) and a plausible failure scenario has come up in = discussions here, which does not appear to be covered, though it certainly seems to be the sort of failure that should be addressed by L= LGR.

 

The scenario happens when we have LLGR = configured on both sides of a number of peering sessions, and BGP speaker (= e.g., a Route Reflector) loses contact with a number of its peers simultaneously. The likely cause would be that the paths to the = peers share a common element that has failed. (And note that the common ele= ment could be part of the BGP speaker in question – something that ca= n be repaired without restarting the system.)

 

When contact with this set of peers is = re-established, the scenario has many of the same semantics of a restart. I= n particular, it would be best to delay sending End-of-RIB indications to any of the members of this set of peers until End-Of-RIB to= any of them, or until a reasonable timeout expires after the first comes b= ack. Without this delay, the one BGP speaker would likely send each of the = peers a large number of advertisements with the LLGR_STALE attribute (for the stale routes held for the other dis= connected peers), followed by a large number of advertisements of the those= same routes without the LLGR_STALE attribute (as those routes are refreshe= d by the other peers). There would likely be no change in reachability throughout the network, but there coul= d be a significant amount of FIB thrashing and transient spikes in forwardi= ng traffic, as well as a significant BGP-related I/O and processing load on= each of the speakers.

 

While it seems like a restart, it is of= course not a restart. And as far as the peers which remain connected are c= oncerned, it does not appear anything like a restart at all.

 

While it is possible to imagine an impl= ementation of LLGR that addresses this issue outside of the specification, = I think it would be best if the specification handled this scenario better, whether through a change in the protocol or additional im= plementation advice.

 

--

      &nb= sp; pdm

 

 

 


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

 

--_000_458f7a3d7c32425f99bac4cc0608d30cBL2PR05MB161namprd05pro_-- From nobody Fri Apr 4 15:47:29 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AA81A01B0 for ; Fri, 4 Apr 2014 15:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=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 CkF1Yc1p2RfI for ; Fri, 4 Apr 2014 15:47:23 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C0D1E1A018D for ; Fri, 4 Apr 2014 15:47:23 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id y20so4069886ier.13 for ; Fri, 04 Apr 2014 15:47:19 -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:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=6hobWitEzaO9jIQEy2sohRNJwlzo44BYwRqv1PZoZ4Q=; b=i/fhtbleSD1Djh5ClFATLkI+WV8IGLdzXb2MA5YMnn1JvsBybgY2B4JgHu9fCyORnY vzj7RnEU8CJK16r5FRUaJEnYfC/XKC/I7JrsYPnd2HLdibcq65LJWPajaYLIrhVPPzdE S3Klj58WLOSS9kkMCZwk7whCcXDNyQ4F+tOZhlAXs+O9GdyTBqmBXWl5oLDk5PQzvPrc SDqEZicPf0+1eL7HHn0xQpgoVzyx1sUng0sTwjncZ7HVP+TJwjXQh2M/qgZ56bLOkpFO 7TY4DKzFpje/+7vJkTZuMuvyYR2mUsEXprWLoJTdU3BrVcj6f8cV/3JV6V/vmbyiRvIK RC+Q== MIME-Version: 1.0 X-Received: by 10.43.143.211 with SMTP id jn19mr15051256icc.0.1396651639080; Fri, 04 Apr 2014 15:47:19 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 4 Apr 2014 15:47:19 -0700 (PDT) In-Reply-To: <458f7a3d7c32425f99bac4cc0608d30c@BL2PR05MB161.namprd05.prod.outlook.com> References: <2f22313a3a5c4c278e5517aca8463dba@BL2PR05MB161.namprd05.prod.outlook.com> <458f7a3d7c32425f99bac4cc0608d30c@BL2PR05MB161.namprd05.prod.outlook.com> Date: Sat, 5 Apr 2014 00:47:19 +0200 X-Google-Sender-Auth: -B2AxjU0RX4nR_Uc2B-8ICDxIoQ Message-ID: From: Robert Raszuk To: Paul Mattes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HJn011rst68-FjnWv-PjMtKDqLU Cc: "idr@ietf.org" Subject: Re: [Idr] Possible weakness in long-lived graceful restart X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 22:47:28 -0000 Hi Paul, I actually do not see why you envision double advertisements. The amount of advertisement depends on two factors: - Duration of "Long-lived Session Read Only Timer" - if this is long enough and all peers in the LLGR-stale group would manage to restart - overall best path would be send. We do need this timer not to wait forever for EOR from each member of this group. - The fact that some peers will restart later then "Long-lived Session Read Only Timer" does not really mean that you will see full table again in all peers. Only if such peers paths would become best you will see the paths re-advertised .. so likely it would be small delta of overall number of paths. > But the best case, and I think the typical case with the read-only timer,= would > also be double advertisements of each route - once with LLGR_STALE attach= ed, > and once without it. > > Can we do better still? My hope is to avoid sending out that first wave o= f > LLGR_STALE routes, too, if we can. Or am I misunderstanding how your > mechanism would work? If you are talking after restart then not really. Those restarted and selected as best would be advertised when "Long-lived Session Read Only Timer" without the STALE mark. If you are referring to original advertisement when sessions go down then again .. unless there is no other best only then they will be advertised with such MARK, but this is what this entire persistence is all about after all :) Please let me know if you have any questions ... Cheers, R. On Sat, Apr 5, 2014 at 12:26 AM, Paul Mattes wrote: > > I agree that my original suggestion of just suppressing End-of-RIB wouldn= 't help much with the thrashing. So this appears less like a partial-restar= t scenario than I had thought. > > > > I see that your solution could avoid a lot thrashing. The router implemen= ting this procedure would still initially advertise its stale RIB (some rou= tes LLGR-stale, some not) to each of the newly-re-established peers, and se= nd End-of-RIB. The new timer would prevent it from advertising intermediate= states for routes from the group, until each of the peers has sent End-of-= RIB. Then it would re-advertise whichever routes are now best, looking like= something close to the last state they were advertised in before the disas= ter. The worst case for this is advertising every route from the group twic= e, which is much better than the existing worst case, which is (I think) ad= vertising every route N times, where N is the number of peers that disconne= cted. > > > > But the best case, and I think the typical case with the read-only timer,= would also be double advertisements of each route - once with LLGR_STALE a= ttached, and once without it. > > > > Can we do better still? My hope is to avoid sending out that first wave o= f LLGR_STALE routes, too, if we can. Or am I misunderstanding how your mech= anism would work? > > > > -- > > pdm > > > > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Ra= szuk > Sent: Friday, April 04, 2014 3:32 PM > To: Paul Mattes > Cc: idr@ietf.org > Subject: Re: [Idr] Possible weakness in long-lived graceful restart > > > > Hi Paul, > > > > I think your observation is valid and possible in real deployments howeve= r the fix you are asking for may be slightly. > > > > First let's observe that "Restart Time" and "Long lived Stale Time" is pe= r session and defined procedures are also per session. > > > > To apply any solution it would be required to find a way to dynamically g= roup peers which may belong to the same "peer failure risk group", but that= is hard as IBGP sessions to those peers naturally are designed to work aro= und single network failures. > > > > An option could be perhaps to treat all peers running in under "Long live= d Stale Time" state as one group and then define a "Long Lived Read Only Ti= mer" which would start from the first session previously in such group to g= et re-established and till it expires suppress any best path computation ba= sed on the newly received paths from those peers. > > > > Literally what you are pointing out could be fixed by the following text = addition to "draft-uttaro-idr-bgp-persistence-03" section 4.2: > > > > Current text: > > > > > > Once the session is re-established, the procedures specified in [RFC4724]= apply for the stale routes irrespective of whether the stale routes are re= tained during the"Restart Time" period or the "Long-lived Stale Time" perio= d. > > However, in the case of consecutive restarts (i.e,the session goes down b= efore the EoR is received) the previously marked stale routes MUST NOT be d= eleted before the timer for the "Long-lived Stale Time" expires. > > > > New text: > > > > All sessions in "Long-lived Stale Time" are grouped into "Long-lived Sess= ions Group". New timer called "Long-lived Session Read Only Timer" is defin= ed. > > > > > > Once the session is re-established, the procedures specified in [RFC4724] > > > > apply for the stale routes irrespective of whether the stale routes are r= etained during the"Restart Time" period or the "Long-lived Stale Time" peri= od except that such procedures are delayed for the peers belonging to "Long= -lived > > Sessions Group" till all members of the group send EOR message or the > > "Long-lived Session Read Only Timer" expires. > > > > > > The "Long-lived Session Read Only Timer" is started upon reestablishment = ofthe first session belonging to "Long-lived Sessions Group". > > > > However, in the case of consecutive restarts (i.e, the session goes down > > > > before the EoR is received) the previously marked stale routes MUST NOT > > > > be deleted before the timer for the "Long-lived Stale Time" expires. > > > > > > > > > > > > Best regards, > > R. > > > > > > > > On Fri, Apr 4, 2014 at 9:45 PM, Paul Mattes wrote: > > I have been doing some work on long-lived graceful restart (LLGR) and a p= lausible failure scenario has come up in discussions here, which does not a= ppear to be covered, though it certainly seems to be the sort of failure th= at should be addressed by LLGR. > > > > The scenario happens when we have LLGR configured on both sides of a numb= er of peering sessions, and BGP speaker (e.g., a Route Reflector) loses con= tact with a number of its peers simultaneously. The likely cause would be t= hat the paths to the peers share a common element that has failed. (And not= e that the common element could be part of the BGP speaker in question - so= mething that can be repaired without restarting the system.) > > > > When contact with this set of peers is re-established, the scenario has m= any of the same semantics of a restart. In particular, it would be best to = delay sending End-of-RIB indications to any of the members of this set of p= eers until End-Of-RIB to any of them, or until a reasonable timeout expires= after the first comes back. Without this delay, the one BGP speaker would = likely send each of the peers a large number of advertisements with the LLG= R_STALE attribute (for the stale routes held for the other disconnected pee= rs), followed by a large number of advertisements of the those same routes = without the LLGR_STALE attribute (as those routes are refreshed by the othe= r peers). There would likely be no change in reachability throughout the ne= twork, but there could be a significant amount of FIB thrashing and transie= nt spikes in forwarding traffic, as well as a significant BGP-related I/O a= nd processing load on each of the speakers. > > > > While it seems like a restart, it is of course not a restart. And as far = as the peers which remain connected are concerned, it does not appear anyth= ing like a restart at all. > > > > While it is possible to imagine an implementation of LLGR that addresses = this issue outside of the specification, I think it would be best if the sp= ecification handled this scenario better, whether through a change in the p= rotocol or additional implementation advice. > > > > -- > > pdm > > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From nobody Fri Apr 4 16:07:30 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A209C1A02AF for ; Fri, 4 Apr 2014 16:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 Pq7hDVSKDk2l for ; Fri, 4 Apr 2014 16:07:23 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id EAC3D1A025A for ; Fri, 4 Apr 2014 16:07:14 -0700 (PDT) Received: from mail114-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Fri, 4 Apr 2014 23:07:05 +0000 Received: from mail114-va3 (localhost [127.0.0.1]) by mail114-va3-R.bigfish.com (Postfix) with ESMTP id D89991C0097; Fri, 4 Apr 2014 23:07:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371I542I1432Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail114-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=pmattes@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(13464003)(377454003)(24454002)(199002)(189002)(15975445006)(77982001)(81542001)(95416001)(90146001)(65816001)(31966008)(74876001)(94946001)(81816001)(33646001)(81686001)(79102001)(74706001)(81342001)(80022001)(97336001)(59766001)(20776003)(66066001)(85852003)(87936001)(83072002)(97186001)(63696002)(74502001)(19580395003)(54356001)(85306002)(46102001)(86362001)(76576001)(2656002)(76796001)(92566001)(76786001)(77096001)(99286001)(99396002)(98676001)(94316002)(49866001)(47736001)(47976001)(50986001)(93136001)(54316002)(69226001)(19580405001)(93516002)(51856001)(53806001)(56816005)(74662001)(95666003)(87266001)(83322001)(4396001)(47446002)(80976001)(56776001)(74366001)(74316001)(76482001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB161; H:BL2PR05MB161.namprd05.prod.outlook.com; FPR:EEF7F1E9.A4FA5F11.73D33173.4EE8D170.206CA; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail114-va3 (localhost.localdomain [127.0.0.1]) by mail114-va3 (MessageSwitch) id 1396652822231603_21344; Fri, 4 Apr 2014 23:07:02 +0000 (UTC) Received: from VA3EHSMHS040.bigfish.com (unknown [10.7.14.252]) by mail114-va3.bigfish.com (Postfix) with ESMTP id 291BA60070; Fri, 4 Apr 2014 23:07:02 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS040.bigfish.com (10.7.99.50) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 4 Apr 2014 23:07:02 +0000 Received: from BL2PR05MB161.namprd05.prod.outlook.com (10.242.198.13) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 4 Apr 2014 23:07:06 +0000 Received: from BL2PR05MB161.namprd05.prod.outlook.com (10.242.198.13) by BL2PR05MB161.namprd05.prod.outlook.com (10.242.198.13) with Microsoft SMTP Server (TLS) id 15.0.913.9; Fri, 4 Apr 2014 23:07:05 +0000 Received: from BL2PR05MB161.namprd05.prod.outlook.com ([169.254.12.68]) by BL2PR05MB161.namprd05.prod.outlook.com ([169.254.12.68]) with mapi id 15.00.0913.002; Fri, 4 Apr 2014 23:07:05 +0000 From: Paul Mattes To: Robert Raszuk Thread-Topic: [Idr] Possible weakness in long-lived graceful restart Thread-Index: Ac9QO9JE+CyeW2xWRcmYZ+xCsyyfPwACSfEAAAMMYZAAAap3gAAAT6Ig Date: Fri, 4 Apr 2014 23:07:04 +0000 Message-ID: References: <2f22313a3a5c4c278e5517aca8463dba@BL2PR05MB161.namprd05.prod.outlook.com> <458f7a3d7c32425f99bac4cc0608d30c@BL2PR05MB161.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 01713B2841 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/idr/o8cqM2TH8h2KTyq_efW_aD1wHjY Cc: "idr@ietf.org" Subject: Re: [Idr] Possible weakness in long-lived graceful restart X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 23:07:28 -0000 Then I'm definitely missing something. But it wouldn't be the first time. ;= -) Let's call the router implementing this new timer R, and the other routers = A, B and C. (1) R loses contact with A, B and C. (2) The outage lasts long enough for R to go into LLGR helper mode for each= . (3) R puts A, B and C into a group. At this point, the best paths for some number of routes in R's RIB came fro= m A, B or C. So it marks them with LLGR_STALE. (4) A reconnects. (5) R starts the Read-Only timer. (6) B and C reconnect. At this point, A, B and C have not re-advertised anything to R. (7) R advertises what it has to A, B and C. That includes the LLGR_STALE ro= utes mentioned above. (8) A, B and C re-advertise their routes. The Read-Only timer prevents thes= e routes from being use for best path computations, so nothing is re-advert= ised. (9) A, B and C send End-of-RIB. (10) R runs best path on any routes that A, B or C refreshed. (11) R re-advertises any routes whose best path has now changed, or that no= w have the LLGR_STALE community removed because they were refreshed. So I think the point of confusion is step (7), where R sends its current RI= B to the peers, which would include stale routes from B and C sent to A, st= ale routes from A and C sent to B, and stale routes from A and B sent to C.= Or is something keeping R from doing that? -- pdm -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Friday, April 04, 2014 5:47 PM To: Paul Mattes Cc: idr@ietf.org Subject: Re: [Idr] Possible weakness in long-lived graceful restart Hi Paul, I actually do not see why you envision double advertisements. The amount of advertisement depends on two factors: - Duration of "Long-lived Session Read Only Timer" - if this is long enough= and all peers in the LLGR-stale group would manage to restart - overall be= st path would be send. We do need this timer not to wait forever for EOR fr= om each member of this group. - The fact that some peers will restart later then "Long-lived Session Read= Only Timer" does not really mean that you will see full table again in all= peers. Only if such peers paths would become best you will see the paths r= e-advertised .. so likely it would be small delta of overall number of path= s. > But the best case, and I think the typical case with the read-only=20 > timer, would also be double advertisements of each route - once with=20 > LLGR_STALE attached, and once without it. > > Can we do better still? My hope is to avoid sending out that first=20 > wave of LLGR_STALE routes, too, if we can. Or am I misunderstanding=20 > how your mechanism would work? If you are talking after restart then not really. Those restarted and selec= ted as best would be advertised when "Long-lived Session Read Only Timer" w= ithout the STALE mark. If you are referring to original advertisement when sessions go down then a= gain .. unless there is no other best only then they will be advertised wit= h such MARK, but this is what this entire persistence is all about after al= l :) Please let me know if you have any questions ... Cheers, R. On Sat, Apr 5, 2014 at 12:26 AM, Paul Mattes wrote: > > I agree that my original suggestion of just suppressing End-of-RIB wouldn= 't help much with the thrashing. So this appears less like a partial-restar= t scenario than I had thought. > > > > I see that your solution could avoid a lot thrashing. The router implemen= ting this procedure would still initially advertise its stale RIB (some rou= tes LLGR-stale, some not) to each of the newly-re-established peers, and se= nd End-of-RIB. The new timer would prevent it from advertising intermediate= states for routes from the group, until each of the peers has sent End-of-= RIB. Then it would re-advertise whichever routes are now best, looking like= something close to the last state they were advertised in before the disas= ter. The worst case for this is advertising every route from the group twic= e, which is much better than the existing worst case, which is (I think) ad= vertising every route N times, where N is the number of peers that disconne= cted. > > > > But the best case, and I think the typical case with the read-only timer,= would also be double advertisements of each route - once with LLGR_STALE a= ttached, and once without it. > > > > Can we do better still? My hope is to avoid sending out that first wave o= f LLGR_STALE routes, too, if we can. Or am I misunderstanding how your mech= anism would work? > > > > -- > > pdm > > > > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert=20 > Raszuk > Sent: Friday, April 04, 2014 3:32 PM > To: Paul Mattes > Cc: idr@ietf.org > Subject: Re: [Idr] Possible weakness in long-lived graceful restart > > > > Hi Paul, > > > > I think your observation is valid and possible in real deployments howeve= r the fix you are asking for may be slightly. > > > > First let's observe that "Restart Time" and "Long lived Stale Time" is pe= r session and defined procedures are also per session. > > > > To apply any solution it would be required to find a way to dynamically g= roup peers which may belong to the same "peer failure risk group", but that= is hard as IBGP sessions to those peers naturally are designed to work aro= und single network failures. > > > > An option could be perhaps to treat all peers running in under "Long live= d Stale Time" state as one group and then define a "Long Lived Read Only Ti= mer" which would start from the first session previously in such group to g= et re-established and till it expires suppress any best path computation ba= sed on the newly received paths from those peers. > > > > Literally what you are pointing out could be fixed by the following text = addition to "draft-uttaro-idr-bgp-persistence-03" section 4.2: > > > > Current text: > > > > > > Once the session is re-established, the procedures specified in [RFC4724]= apply for the stale routes irrespective of whether the stale routes are re= tained during the"Restart Time" period or the "Long-lived Stale Time" perio= d. > > However, in the case of consecutive restarts (i.e,the session goes down b= efore the EoR is received) the previously marked stale routes MUST NOT be d= eleted before the timer for the "Long-lived Stale Time" expires. > > > > New text: > > > > All sessions in "Long-lived Stale Time" are grouped into "Long-lived Sess= ions Group". New timer called "Long-lived Session Read Only Timer" is defin= ed. > > > > > > Once the session is re-established, the procedures specified in=20 > [RFC4724] > > > > apply for the stale routes irrespective of whether the stale routes=20 > are retained during the"Restart Time" period or the "Long-lived Stale=20 > Time" period except that such procedures are delayed for the peers=20 > belonging to "Long-lived > > Sessions Group" till all members of the group send EOR message or the > > "Long-lived Session Read Only Timer" expires. > > > > > > The "Long-lived Session Read Only Timer" is started upon reestablishment = ofthe first session belonging to "Long-lived Sessions Group". > > > > However, in the case of consecutive restarts (i.e, the session goes=20 > down > > > > before the EoR is received) the previously marked stale routes MUST=20 > NOT > > > > be deleted before the timer for the "Long-lived Stale Time" expires. > > > > > > > > > > > > Best regards, > > R. > > > > > > > > On Fri, Apr 4, 2014 at 9:45 PM, Paul Mattes wrote: > > I have been doing some work on long-lived graceful restart (LLGR) and a p= lausible failure scenario has come up in discussions here, which does not a= ppear to be covered, though it certainly seems to be the sort of failure th= at should be addressed by LLGR. > > > > The scenario happens when we have LLGR configured on both sides of a=20 > number of peering sessions, and BGP speaker (e.g., a Route Reflector)=20 > loses contact with a number of its peers simultaneously. The likely=20 > cause would be that the paths to the peers share a common element that=20 > has failed. (And note that the common element could be part of the BGP=20 > speaker in question - something that can be repaired without=20 > restarting the system.) > > > > When contact with this set of peers is re-established, the scenario has m= any of the same semantics of a restart. In particular, it would be best to = delay sending End-of-RIB indications to any of the members of this set of p= eers until End-Of-RIB to any of them, or until a reasonable timeout expires= after the first comes back. Without this delay, the one BGP speaker would = likely send each of the peers a large number of advertisements with the LLG= R_STALE attribute (for the stale routes held for the other disconnected pee= rs), followed by a large number of advertisements of the those same routes = without the LLGR_STALE attribute (as those routes are refreshed by the othe= r peers). There would likely be no change in reachability throughout the ne= twork, but there could be a significant amount of FIB thrashing and transie= nt spikes in forwarding traffic, as well as a significant BGP-related I/O a= nd processing load on each of the speakers. > > > > While it seems like a restart, it is of course not a restart. And as far = as the peers which remain connected are concerned, it does not appear anyth= ing like a restart at all. > > > > While it is possible to imagine an implementation of LLGR that addresses = this issue outside of the specification, I think it would be best if the sp= ecification handled this scenario better, whether through a change in the p= rotocol or additional implementation advice. > > > > -- > > pdm > > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From nobody Fri Apr 4 16:20:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45811A01E8 for ; Fri, 4 Apr 2014 16:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=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 tBAC_YmmSPq9 for ; Fri, 4 Apr 2014 16:20:07 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id B07F51A01E1 for ; Fri, 4 Apr 2014 16:20:07 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rd18so4069432iec.21 for ; Fri, 04 Apr 2014 16:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=cJBcwWA+R1gkwdNb58OIeBpCmX60ZhcbKrySGRfSgdE=; b=VNNZBwSWBax2shqvgvqS0Iq2KCGTkpv7eEIFz+oTtM3fGtign6DZIVNETZqagJcx1c vLoQo9o8iTAba36ubLml+FaV/OTHxLGHn16Ws3AWR3fC/8NmptNvvQ3tEYeEzogtI2IF hTl9ARVTN8CCImIITTJ1t6XRmFQGRuGKlkYAdZkCQ5BnjcoVEDXkzPT/O0O5/AO/fZ/o gM2jtjoxjGeVOV6j5vteDV1g0Q52AYpGFRqY/duKUdS1aCrkjI3B0Rdzht1YodmKMyHZ R8PrqBIyzTQNDv5SaOX6NL90ns8gAOXnK3VjvcPafMEaEmEAzulXEmIruqLb9EqXfddc 7Ssg== MIME-Version: 1.0 X-Received: by 10.50.43.225 with SMTP id z1mr6133284igl.29.1396653602849; Fri, 04 Apr 2014 16:20:02 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 4 Apr 2014 16:20:02 -0700 (PDT) In-Reply-To: References: <2f22313a3a5c4c278e5517aca8463dba@BL2PR05MB161.namprd05.prod.outlook.com> <458f7a3d7c32425f99bac4cc0608d30c@BL2PR05MB161.namprd05.prod.outlook.com> Date: Sat, 5 Apr 2014 01:20:02 +0200 X-Google-Sender-Auth: 9X-Gp5RSfeKneEM8NGPvthMmjLs Message-ID: From: Robert Raszuk To: Paul Mattes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/pBvOJ1ubpbFiNgDbrpao3ugmP0Y Cc: "idr@ietf.org" Subject: Re: [Idr] Possible weakness in long-lived graceful restart X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 23:20:11 -0000 Hi Paul, If A, B & C have not readvisrtised their non stale (any longer) paths to R then R would not compute its best path (no trigger) and would not advertised anything to them. Keep in mind that Read-Only mode is called such for a reason .. there is no advertisement done during that time to peers in such RO mode. Here we are just creating a new group and applying new timer .. but the basic behavior stays as it is today. Cheers, R. On Sat, Apr 5, 2014 at 1:07 AM, Paul Mattes wrote: > Then I'm definitely missing something. But it wouldn't be the first time.= ;-) > > Let's call the router implementing this new timer R, and the other router= s A, B and C. > > (1) R loses contact with A, B and C. > (2) The outage lasts long enough for R to go into LLGR helper mode for ea= ch. > (3) R puts A, B and C into a group. > > At this point, the best paths for some number of routes in R's RIB came f= rom A, B or C. So it marks them with LLGR_STALE. > > (4) A reconnects. > (5) R starts the Read-Only timer. > (6) B and C reconnect. > > At this point, A, B and C have not re-advertised anything to R. > > (7) R advertises what it has to A, B and C. That includes the LLGR_STALE = routes mentioned above. > > (8) A, B and C re-advertise their routes. The Read-Only timer prevents th= ese routes from being use for best path computations, so nothing is re-adve= rtised. > (9) A, B and C send End-of-RIB. > (10) R runs best path on any routes that A, B or C refreshed. > (11) R re-advertises any routes whose best path has now changed, or that = now have the LLGR_STALE community removed because they were refreshed. > > So I think the point of confusion is step (7), where R sends its current = RIB to the peers, which would include stale routes from B and C sent to A, = stale routes from A and C sent to B, and stale routes from A and B sent to = C. Or is something keeping R from doing that? > > -- > pdm > > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Ra= szuk > Sent: Friday, April 04, 2014 5:47 PM > To: Paul Mattes > Cc: idr@ietf.org > Subject: Re: [Idr] Possible weakness in long-lived graceful restart > > Hi Paul, > > I actually do not see why you envision double advertisements. > > The amount of advertisement depends on two factors: > > - Duration of "Long-lived Session Read Only Timer" - if this is long enou= gh and all peers in the LLGR-stale group would manage to restart - overall = best path would be send. We do need this timer not to wait forever for EOR = from each member of this group. > > - The fact that some peers will restart later then "Long-lived Session Re= ad Only Timer" does not really mean that you will see full table again in a= ll peers. Only if such peers paths would become best you will see the paths= re-advertised .. so likely it would be small delta of overall number of pa= ths. > >> But the best case, and I think the typical case with the read-only >> timer, would also be double advertisements of each route - once with >> LLGR_STALE attached, and once without it. >> >> Can we do better still? My hope is to avoid sending out that first >> wave of LLGR_STALE routes, too, if we can. Or am I misunderstanding >> how your mechanism would work? > > If you are talking after restart then not really. Those restarted and sel= ected as best would be advertised when "Long-lived Session Read Only Timer"= without the STALE mark. > > If you are referring to original advertisement when sessions go down then= again .. unless there is no other best only then they will be advertised w= ith such MARK, but this is what this entire persistence is all about after = all :) > > Please let me know if you have any questions ... > > Cheers, > R. > > On Sat, Apr 5, 2014 at 12:26 AM, Paul Mattes wrote: >> >> I agree that my original suggestion of just suppressing End-of-RIB would= n't help much with the thrashing. So this appears less like a partial-resta= rt scenario than I had thought. >> >> >> >> I see that your solution could avoid a lot thrashing. The router impleme= nting this procedure would still initially advertise its stale RIB (some ro= utes LLGR-stale, some not) to each of the newly-re-established peers, and s= end End-of-RIB. The new timer would prevent it from advertising intermediat= e states for routes from the group, until each of the peers has sent End-of= -RIB. Then it would re-advertise whichever routes are now best, looking lik= e something close to the last state they were advertised in before the disa= ster. The worst case for this is advertising every route from the group twi= ce, which is much better than the existing worst case, which is (I think) a= dvertising every route N times, where N is the number of peers that disconn= ected. >> >> >> >> But the best case, and I think the typical case with the read-only timer= , would also be double advertisements of each route - once with LLGR_STALE = attached, and once without it. >> >> >> >> Can we do better still? My hope is to avoid sending out that first wave = of LLGR_STALE routes, too, if we can. Or am I misunderstanding how your mec= hanism would work? >> >> >> >> -- >> >> pdm >> >> >> >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Friday, April 04, 2014 3:32 PM >> To: Paul Mattes >> Cc: idr@ietf.org >> Subject: Re: [Idr] Possible weakness in long-lived graceful restart >> >> >> >> Hi Paul, >> >> >> >> I think your observation is valid and possible in real deployments howev= er the fix you are asking for may be slightly. >> >> >> >> First let's observe that "Restart Time" and "Long lived Stale Time" is p= er session and defined procedures are also per session. >> >> >> >> To apply any solution it would be required to find a way to dynamically = group peers which may belong to the same "peer failure risk group", but tha= t is hard as IBGP sessions to those peers naturally are designed to work ar= ound single network failures. >> >> >> >> An option could be perhaps to treat all peers running in under "Long liv= ed Stale Time" state as one group and then define a "Long Lived Read Only T= imer" which would start from the first session previously in such group to = get re-established and till it expires suppress any best path computation b= ased on the newly received paths from those peers. >> >> >> >> Literally what you are pointing out could be fixed by the following text= addition to "draft-uttaro-idr-bgp-persistence-03" section 4.2: >> >> >> >> Current text: >> >> >> >> >> >> Once the session is re-established, the procedures specified in [RFC4724= ] apply for the stale routes irrespective of whether the stale routes are r= etained during the"Restart Time" period or the "Long-lived Stale Time" peri= od. >> >> However, in the case of consecutive restarts (i.e,the session goes down = before the EoR is received) the previously marked stale routes MUST NOT be = deleted before the timer for the "Long-lived Stale Time" expires. >> >> >> >> New text: >> >> >> >> All sessions in "Long-lived Stale Time" are grouped into "Long-lived Ses= sions Group". New timer called "Long-lived Session Read Only Timer" is defi= ned. >> >> >> >> >> >> Once the session is re-established, the procedures specified in >> [RFC4724] >> >> >> >> apply for the stale routes irrespective of whether the stale routes >> are retained during the"Restart Time" period or the "Long-lived Stale >> Time" period except that such procedures are delayed for the peers >> belonging to "Long-lived >> >> Sessions Group" till all members of the group send EOR message or the >> >> "Long-lived Session Read Only Timer" expires. >> >> >> >> >> >> The "Long-lived Session Read Only Timer" is started upon reestablishment= ofthe first session belonging to "Long-lived Sessions Group". >> >> >> >> However, in the case of consecutive restarts (i.e, the session goes >> down >> >> >> >> before the EoR is received) the previously marked stale routes MUST >> NOT >> >> >> >> be deleted before the timer for the "Long-lived Stale Time" expires. >> >> >> >> >> >> >> >> >> >> >> >> Best regards, >> >> R. >> >> >> >> >> >> >> >> On Fri, Apr 4, 2014 at 9:45 PM, Paul Mattes wrote: >> >> I have been doing some work on long-lived graceful restart (LLGR) and a = plausible failure scenario has come up in discussions here, which does not = appear to be covered, though it certainly seems to be the sort of failure t= hat should be addressed by LLGR. >> >> >> >> The scenario happens when we have LLGR configured on both sides of a >> number of peering sessions, and BGP speaker (e.g., a Route Reflector) >> loses contact with a number of its peers simultaneously. The likely >> cause would be that the paths to the peers share a common element that >> has failed. (And note that the common element could be part of the BGP >> speaker in question - something that can be repaired without >> restarting the system.) >> >> >> >> When contact with this set of peers is re-established, the scenario has = many of the same semantics of a restart. In particular, it would be best to= delay sending End-of-RIB indications to any of the members of this set of = peers until End-Of-RIB to any of them, or until a reasonable timeout expire= s after the first comes back. Without this delay, the one BGP speaker would= likely send each of the peers a large number of advertisements with the LL= GR_STALE attribute (for the stale routes held for the other disconnected pe= ers), followed by a large number of advertisements of the those same routes= without the LLGR_STALE attribute (as those routes are refreshed by the oth= er peers). There would likely be no change in reachability throughout the n= etwork, but there could be a significant amount of FIB thrashing and transi= ent spikes in forwarding traffic, as well as a significant BGP-related I/O = and processing load on each of the speakers. >> >> >> >> While it seems like a restart, it is of course not a restart. And as far= as the peers which remain connected are concerned, it does not appear anyt= hing like a restart at all. >> >> >> >> While it is possible to imagine an implementation of LLGR that addresses= this issue outside of the specification, I think it would be best if the s= pecification handled this scenario better, whether through a change in the = protocol or additional implementation advice. >> >> >> >> -- >> >> pdm >> >> >> >> >> >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> > > > From nobody Mon Apr 7 13:00:13 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17321A026F for ; Mon, 7 Apr 2014 13:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 b8Wh7BkuwwNx for ; Mon, 7 Apr 2014 13:00:06 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id E01591A026E for ; Mon, 7 Apr 2014 13:00:05 -0700 (PDT) Received: from mail110-ch1-R.bigfish.com (10.43.68.236) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Mon, 7 Apr 2014 19:59:45 +0000 Received: from mail110-ch1 (localhost [127.0.0.1]) by mail110-ch1-R.bigfish.com (Postfix) with ESMTP id 045874204B7; Mon, 7 Apr 2014 19:59:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371I542I1432Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail110-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=pmattes@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(13464003)(377454003)(189002)(51704005)(199002)(83322001)(69226001)(74366001)(74876001)(95666003)(63696002)(47736001)(94946001)(74706001)(31966008)(99396002)(33646001)(90146001)(77982001)(94316002)(20776003)(79102001)(65816001)(83072002)(59766001)(2656002)(92566001)(80022001)(46102001)(85852003)(98676001)(54356001)(81542001)(19580405001)(86362001)(74316001)(47446002)(66066001)(74662001)(95416001)(80976001)(74502001)(54316002)(56776001)(76576001)(97336001)(93516002)(93136001)(81342001)(53806001)(97186001)(47976001)(76796001)(81816001)(77096001)(15975445006)(76786001)(50986001)(85306002)(76482001)(49866001)(87266001)(56816005)(81686001)(4396001)(19580395003)(87936001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB176; H:BY2PR05MB174.namprd05.prod.outlook.com; FPR:EEF7F1E9.A4FA5F11.73D33173.4EE8D150.2072B; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail110-ch1 (localhost.localdomain [127.0.0.1]) by mail110-ch1 (MessageSwitch) id 1396900783650672_5239; Mon, 7 Apr 2014 19:59:43 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail110-ch1.bigfish.com (Postfix) with ESMTP id 90F98800E7; Mon, 7 Apr 2014 19:59:43 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 7 Apr 2014 19:59:43 +0000 Received: from BY2PR05MB176.namprd05.prod.outlook.com (10.242.39.141) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.435.0; Mon, 7 Apr 2014 19:59:57 +0000 Received: from BY2PR05MB174.namprd05.prod.outlook.com (10.242.39.150) by BY2PR05MB176.namprd05.prod.outlook.com (10.242.39.141) with Microsoft SMTP Server (TLS) id 15.0.908.10; Mon, 7 Apr 2014 19:59:54 +0000 Received: from BY2PR05MB174.namprd05.prod.outlook.com ([169.254.11.63]) by BY2PR05MB174.namprd05.prod.outlook.com ([169.254.11.180]) with mapi id 15.00.0898.005; Mon, 7 Apr 2014 19:59:54 +0000 From: Paul Mattes To: Robert Raszuk Thread-Topic: [Idr] Possible weakness in long-lived graceful restart Thread-Index: Ac9QO9JE+CyeW2xWRcmYZ+xCsyyfPwACSfEAAAMMYZAAAap3gAAAT6IgAADU4QAAj1nNUA== Date: Mon, 7 Apr 2014 19:59:53 +0000 Message-ID: References: <2f22313a3a5c4c278e5517aca8463dba@BL2PR05MB161.namprd05.prod.outlook.com> <458f7a3d7c32425f99bac4cc0608d30c@BL2PR05MB161.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 0174BD4BDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/idr/DZw-PivTK5bRcAGGDQ4ErtNGYCo Cc: "idr@ietf.org" Subject: Re: [Idr] Possible weakness in long-lived graceful restart X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 20:00:11 -0000 Then what I missed was that the R would not advertise anything *to* A, B or= C until the Read-Only timer expired. Then I agree that A, B and C are like= ly to receive only one set of updates of one another's routes. Also routers= D and E (other peers of R, not affected by the outage) would receive only = one set of updates for routes that originated from A, B and C. All good -- = thank you for your feedback and patience. -- pdm -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Friday, April 04, 2014 6:20 PM To: Paul Mattes Cc: idr@ietf.org Subject: Re: [Idr] Possible weakness in long-lived graceful restart Hi Paul, If A, B & C have not readvisrtised their non stale (any longer) paths to R = then R would not compute its best path (no trigger) and would not advertise= d anything to them. Keep in mind that Read-Only mode is called such for a reason .. there is no= advertisement done during that time to peers in such RO mode. Here we are just creating a new group and applying new timer .. but the bas= ic behavior stays as it is today. Cheers, R. On Sat, Apr 5, 2014 at 1:07 AM, Paul Mattes wrote: > Then I'm definitely missing something. But it wouldn't be the first=20 > time. ;-) > > Let's call the router implementing this new timer R, and the other router= s A, B and C. > > (1) R loses contact with A, B and C. > (2) The outage lasts long enough for R to go into LLGR helper mode for ea= ch. > (3) R puts A, B and C into a group. > > At this point, the best paths for some number of routes in R's RIB came f= rom A, B or C. So it marks them with LLGR_STALE. > > (4) A reconnects. > (5) R starts the Read-Only timer. > (6) B and C reconnect. > > At this point, A, B and C have not re-advertised anything to R. > > (7) R advertises what it has to A, B and C. That includes the LLGR_STALE = routes mentioned above. > > (8) A, B and C re-advertise their routes. The Read-Only timer prevents th= ese routes from being use for best path computations, so nothing is re-adve= rtised. > (9) A, B and C send End-of-RIB. > (10) R runs best path on any routes that A, B or C refreshed. > (11) R re-advertises any routes whose best path has now changed, or that = now have the LLGR_STALE community removed because they were refreshed. > > So I think the point of confusion is step (7), where R sends its current = RIB to the peers, which would include stale routes from B and C sent to A, = stale routes from A and C sent to B, and stale routes from A and B sent to = C. Or is something keeping R from doing that? > > -- > pdm > > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert=20 > Raszuk > Sent: Friday, April 04, 2014 5:47 PM > To: Paul Mattes > Cc: idr@ietf.org > Subject: Re: [Idr] Possible weakness in long-lived graceful restart > > Hi Paul, > > I actually do not see why you envision double advertisements. > > The amount of advertisement depends on two factors: > > - Duration of "Long-lived Session Read Only Timer" - if this is long enou= gh and all peers in the LLGR-stale group would manage to restart - overall = best path would be send. We do need this timer not to wait forever for EOR = from each member of this group. > > - The fact that some peers will restart later then "Long-lived Session Re= ad Only Timer" does not really mean that you will see full table again in a= ll peers. Only if such peers paths would become best you will see the paths= re-advertised .. so likely it would be small delta of overall number of pa= ths. > >> But the best case, and I think the typical case with the read-only=20 >> timer, would also be double advertisements of each route - once with=20 >> LLGR_STALE attached, and once without it. >> >> Can we do better still? My hope is to avoid sending out that first=20 >> wave of LLGR_STALE routes, too, if we can. Or am I misunderstanding=20 >> how your mechanism would work? > > If you are talking after restart then not really. Those restarted and sel= ected as best would be advertised when "Long-lived Session Read Only Timer"= without the STALE mark. > > If you are referring to original advertisement when sessions go down=20 > then again .. unless there is no other best only then they will be=20 > advertised with such MARK, but this is what this entire persistence is=20 > all about after all :) > > Please let me know if you have any questions ... > > Cheers, > R. > > On Sat, Apr 5, 2014 at 12:26 AM, Paul Mattes wrote: >> >> I agree that my original suggestion of just suppressing End-of-RIB would= n't help much with the thrashing. So this appears less like a partial-resta= rt scenario than I had thought. >> >> >> >> I see that your solution could avoid a lot thrashing. The router impleme= nting this procedure would still initially advertise its stale RIB (some ro= utes LLGR-stale, some not) to each of the newly-re-established peers, and s= end End-of-RIB. The new timer would prevent it from advertising intermediat= e states for routes from the group, until each of the peers has sent End-of= -RIB. Then it would re-advertise whichever routes are now best, looking lik= e something close to the last state they were advertised in before the disa= ster. The worst case for this is advertising every route from the group twi= ce, which is much better than the existing worst case, which is (I think) a= dvertising every route N times, where N is the number of peers that disconn= ected. >> >> >> >> But the best case, and I think the typical case with the read-only timer= , would also be double advertisements of each route - once with LLGR_STALE = attached, and once without it. >> >> >> >> Can we do better still? My hope is to avoid sending out that first wave = of LLGR_STALE routes, too, if we can. Or am I misunderstanding how your mec= hanism would work? >> >> >> >> -- >> >> pdm >> >> >> >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of=20 >> Robert Raszuk >> Sent: Friday, April 04, 2014 3:32 PM >> To: Paul Mattes >> Cc: idr@ietf.org >> Subject: Re: [Idr] Possible weakness in long-lived graceful restart >> >> >> >> Hi Paul, >> >> >> >> I think your observation is valid and possible in real deployments howev= er the fix you are asking for may be slightly. >> >> >> >> First let's observe that "Restart Time" and "Long lived Stale Time" is p= er session and defined procedures are also per session. >> >> >> >> To apply any solution it would be required to find a way to dynamically = group peers which may belong to the same "peer failure risk group", but tha= t is hard as IBGP sessions to those peers naturally are designed to work ar= ound single network failures. >> >> >> >> An option could be perhaps to treat all peers running in under "Long liv= ed Stale Time" state as one group and then define a "Long Lived Read Only T= imer" which would start from the first session previously in such group to = get re-established and till it expires suppress any best path computation b= ased on the newly received paths from those peers. >> >> >> >> Literally what you are pointing out could be fixed by the following text= addition to "draft-uttaro-idr-bgp-persistence-03" section 4.2: >> >> >> >> Current text: >> >> >> >> >> >> Once the session is re-established, the procedures specified in [RFC4724= ] apply for the stale routes irrespective of whether the stale routes are r= etained during the"Restart Time" period or the "Long-lived Stale Time" peri= od. >> >> However, in the case of consecutive restarts (i.e,the session goes down = before the EoR is received) the previously marked stale routes MUST NOT be = deleted before the timer for the "Long-lived Stale Time" expires. >> >> >> >> New text: >> >> >> >> All sessions in "Long-lived Stale Time" are grouped into "Long-lived Ses= sions Group". New timer called "Long-lived Session Read Only Timer" is defi= ned. >> >> >> >> >> >> Once the session is re-established, the procedures specified in=20 >> [RFC4724] >> >> >> >> apply for the stale routes irrespective of whether the stale routes=20 >> are retained during the"Restart Time" period or the "Long-lived Stale=20 >> Time" period except that such procedures are delayed for the peers=20 >> belonging to "Long-lived >> >> Sessions Group" till all members of the group send EOR message or the >> >> "Long-lived Session Read Only Timer" expires. >> >> >> >> >> >> The "Long-lived Session Read Only Timer" is started upon reestablishment= ofthe first session belonging to "Long-lived Sessions Group". >> >> >> >> However, in the case of consecutive restarts (i.e, the session goes=20 >> down >> >> >> >> before the EoR is received) the previously marked stale routes MUST=20 >> NOT >> >> >> >> be deleted before the timer for the "Long-lived Stale Time" expires. >> >> >> >> >> >> >> >> >> >> >> >> Best regards, >> >> R. >> >> >> >> >> >> >> >> On Fri, Apr 4, 2014 at 9:45 PM, Paul Mattes wrote: >> >> I have been doing some work on long-lived graceful restart (LLGR) and a = plausible failure scenario has come up in discussions here, which does not = appear to be covered, though it certainly seems to be the sort of failure t= hat should be addressed by LLGR. >> >> >> >> The scenario happens when we have LLGR configured on both sides of a=20 >> number of peering sessions, and BGP speaker (e.g., a Route Reflector)=20 >> loses contact with a number of its peers simultaneously. The likely=20 >> cause would be that the paths to the peers share a common element=20 >> that has failed. (And note that the common element could be part of=20 >> the BGP speaker in question - something that can be repaired without=20 >> restarting the system.) >> >> >> >> When contact with this set of peers is re-established, the scenario has = many of the same semantics of a restart. In particular, it would be best to= delay sending End-of-RIB indications to any of the members of this set of = peers until End-Of-RIB to any of them, or until a reasonable timeout expire= s after the first comes back. Without this delay, the one BGP speaker would= likely send each of the peers a large number of advertisements with the LL= GR_STALE attribute (for the stale routes held for the other disconnected pe= ers), followed by a large number of advertisements of the those same routes= without the LLGR_STALE attribute (as those routes are refreshed by the oth= er peers). There would likely be no change in reachability throughout the n= etwork, but there could be a significant amount of FIB thrashing and transi= ent spikes in forwarding traffic, as well as a significant BGP-related I/O = and processing load on each of the speakers. >> >> >> >> While it seems like a restart, it is of course not a restart. And as far= as the peers which remain connected are concerned, it does not appear anyt= hing like a restart at all. >> >> >> >> While it is possible to imagine an implementation of LLGR that addresses= this issue outside of the specification, I think it would be best if the s= pecification handled this scenario better, whether through a change in the = protocol or additional implementation advice. >> >> >> >> -- >> >> pdm >> >> >> >> >> >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> > > > From nobody Mon Apr 7 13:04:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D6B1A026E for ; Mon, 7 Apr 2014 13:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_37=0.6, SPF_PASS=-0.001] autolearn=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 sWvuQQ3yoqgh for ; Mon, 7 Apr 2014 13:03:56 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3385B1A025D for ; Mon, 7 Apr 2014 13:03:56 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id ur14so148230igb.10 for ; Mon, 07 Apr 2014 13:03:50 -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:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=qfE3PTemqUvQUbAVNJrV7UTgwhn6F0NCv+lNhJX77OY=; b=fMv2ai1v+tFO12dCl08WeLvgmssXb2ANbT/Pg1kYLAkpjk99MnyRc3wwBJ65JS5iWa 8hcDK73SeuTIlEIPoQaUaA4gDrA4noRMh8rDMMFwJQ/fDFyJQ6Q1Tr4U109FyA9fFDTz Rm14Rbhvjv3VQPi0OlNOBEcCYbG4LOqAb16rYil5uQc1uzwJHm45s0sDs78I/k96RoH3 hD75NQ/Ymx1eVI6Wb7NrxAyNsR3pSqi88T4gLsIm32pi9M4q0STTqIibySmqPzKT/w02 CI2Ii4isMoanQCSUPPhYne4510AnFMgoiX2fzkMNG5fhFJuZQTRHp6O8M0H2vCRCS3gg Uilw== MIME-Version: 1.0 X-Received: by 10.42.23.82 with SMTP id r18mr8292832icb.43.1396901030294; Mon, 07 Apr 2014 13:03:50 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 7 Apr 2014 13:03:50 -0700 (PDT) In-Reply-To: References: <2f22313a3a5c4c278e5517aca8463dba@BL2PR05MB161.namprd05.prod.outlook.com> <458f7a3d7c32425f99bac4cc0608d30c@BL2PR05MB161.namprd05.prod.outlook.com> Date: Mon, 7 Apr 2014 22:03:50 +0200 X-Google-Sender-Auth: ear7AKnFrk08YeHcbtI3hLvFUMQ Message-ID: From: Robert Raszuk To: Paul Mattes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/eGnwYsGYHpjs1K5dc_8B-PXbCxw Cc: "idr@ietf.org" Subject: Re: [Idr] Possible weakness in long-lived graceful restart X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 20:04:00 -0000 Hi Paul, Yes you are correct. Now I guess if others agree that this is a valid problem to be solved we would need to update the draft with this additional procedure. As this is local optimization we can clearly make it optional to implement so existing implementations do not need to worry about being not compliant ;) Thx, R. On Mon, Apr 7, 2014 at 9:59 PM, Paul Mattes wrote: > Then what I missed was that the R would not advertise anything *to* A, B = or C until the Read-Only timer expired. Then I agree that A, B and C are li= kely to receive only one set of updates of one another's routes. Also route= rs D and E (other peers of R, not affected by the outage) would receive onl= y one set of updates for routes that originated from A, B and C. All good -= - thank you for your feedback and patience. > > -- > pdm > > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Ra= szuk > Sent: Friday, April 04, 2014 6:20 PM > To: Paul Mattes > Cc: idr@ietf.org > Subject: Re: [Idr] Possible weakness in long-lived graceful restart > > Hi Paul, > > If A, B & C have not readvisrtised their non stale (any longer) paths to = R then R would not compute its best path (no trigger) and would not adverti= sed anything to them. > > Keep in mind that Read-Only mode is called such for a reason .. there is = no advertisement done during that time to peers in such RO mode. > Here we are just creating a new group and applying new timer .. but the b= asic behavior stays as it is today. > > Cheers, > R. > > > > > > > On Sat, Apr 5, 2014 at 1:07 AM, Paul Mattes wrote: >> Then I'm definitely missing something. But it wouldn't be the first >> time. ;-) >> >> Let's call the router implementing this new timer R, and the other route= rs A, B and C. >> >> (1) R loses contact with A, B and C. >> (2) The outage lasts long enough for R to go into LLGR helper mode for e= ach. >> (3) R puts A, B and C into a group. >> >> At this point, the best paths for some number of routes in R's RIB came = from A, B or C. So it marks them with LLGR_STALE. >> >> (4) A reconnects. >> (5) R starts the Read-Only timer. >> (6) B and C reconnect. >> >> At this point, A, B and C have not re-advertised anything to R. >> >> (7) R advertises what it has to A, B and C. That includes the LLGR_STALE= routes mentioned above. >> >> (8) A, B and C re-advertise their routes. The Read-Only timer prevents t= hese routes from being use for best path computations, so nothing is re-adv= ertised. >> (9) A, B and C send End-of-RIB. >> (10) R runs best path on any routes that A, B or C refreshed. >> (11) R re-advertises any routes whose best path has now changed, or that= now have the LLGR_STALE community removed because they were refreshed. >> >> So I think the point of confusion is step (7), where R sends its current= RIB to the peers, which would include stale routes from B and C sent to A,= stale routes from A and C sent to B, and stale routes from A and B sent to= C. Or is something keeping R from doing that? >> >> -- >> pdm >> >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Friday, April 04, 2014 5:47 PM >> To: Paul Mattes >> Cc: idr@ietf.org >> Subject: Re: [Idr] Possible weakness in long-lived graceful restart >> >> Hi Paul, >> >> I actually do not see why you envision double advertisements. >> >> The amount of advertisement depends on two factors: >> >> - Duration of "Long-lived Session Read Only Timer" - if this is long eno= ugh and all peers in the LLGR-stale group would manage to restart - overall= best path would be send. We do need this timer not to wait forever for EOR= from each member of this group. >> >> - The fact that some peers will restart later then "Long-lived Session R= ead Only Timer" does not really mean that you will see full table again in = all peers. Only if such peers paths would become best you will see the path= s re-advertised .. so likely it would be small delta of overall number of p= aths. >> >>> But the best case, and I think the typical case with the read-only >>> timer, would also be double advertisements of each route - once with >>> LLGR_STALE attached, and once without it. >>> >>> Can we do better still? My hope is to avoid sending out that first >>> wave of LLGR_STALE routes, too, if we can. Or am I misunderstanding >>> how your mechanism would work? >> >> If you are talking after restart then not really. Those restarted and se= lected as best would be advertised when "Long-lived Session Read Only Timer= " without the STALE mark. >> >> If you are referring to original advertisement when sessions go down >> then again .. unless there is no other best only then they will be >> advertised with such MARK, but this is what this entire persistence is >> all about after all :) >> >> Please let me know if you have any questions ... >> >> Cheers, >> R. >> >> On Sat, Apr 5, 2014 at 12:26 AM, Paul Mattes wrote= : >>> >>> I agree that my original suggestion of just suppressing End-of-RIB woul= dn't help much with the thrashing. So this appears less like a partial-rest= art scenario than I had thought. >>> >>> >>> >>> I see that your solution could avoid a lot thrashing. The router implem= enting this procedure would still initially advertise its stale RIB (some r= outes LLGR-stale, some not) to each of the newly-re-established peers, and = send End-of-RIB. The new timer would prevent it from advertising intermedia= te states for routes from the group, until each of the peers has sent End-o= f-RIB. Then it would re-advertise whichever routes are now best, looking li= ke something close to the last state they were advertised in before the dis= aster. The worst case for this is advertising every route from the group tw= ice, which is much better than the existing worst case, which is (I think) = advertising every route N times, where N is the number of peers that discon= nected. >>> >>> >>> >>> But the best case, and I think the typical case with the read-only time= r, would also be double advertisements of each route - once with LLGR_STALE= attached, and once without it. >>> >>> >>> >>> Can we do better still? My hope is to avoid sending out that first wave= of LLGR_STALE routes, too, if we can. Or am I misunderstanding how your me= chanism would work? >>> >>> >>> >>> -- >>> >>> pdm >>> >>> >>> >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of >>> Robert Raszuk >>> Sent: Friday, April 04, 2014 3:32 PM >>> To: Paul Mattes >>> Cc: idr@ietf.org >>> Subject: Re: [Idr] Possible weakness in long-lived graceful restart >>> >>> >>> >>> Hi Paul, >>> >>> >>> >>> I think your observation is valid and possible in real deployments howe= ver the fix you are asking for may be slightly. >>> >>> >>> >>> First let's observe that "Restart Time" and "Long lived Stale Time" is = per session and defined procedures are also per session. >>> >>> >>> >>> To apply any solution it would be required to find a way to dynamically= group peers which may belong to the same "peer failure risk group", but th= at is hard as IBGP sessions to those peers naturally are designed to work a= round single network failures. >>> >>> >>> >>> An option could be perhaps to treat all peers running in under "Long li= ved Stale Time" state as one group and then define a "Long Lived Read Only = Timer" which would start from the first session previously in such group to= get re-established and till it expires suppress any best path computation = based on the newly received paths from those peers. >>> >>> >>> >>> Literally what you are pointing out could be fixed by the following tex= t addition to "draft-uttaro-idr-bgp-persistence-03" section 4.2: >>> >>> >>> >>> Current text: >>> >>> >>> >>> >>> >>> Once the session is re-established, the procedures specified in [RFC472= 4] apply for the stale routes irrespective of whether the stale routes are = retained during the"Restart Time" period or the "Long-lived Stale Time" per= iod. >>> >>> However, in the case of consecutive restarts (i.e,the session goes down= before the EoR is received) the previously marked stale routes MUST NOT be= deleted before the timer for the "Long-lived Stale Time" expires. >>> >>> >>> >>> New text: >>> >>> >>> >>> All sessions in "Long-lived Stale Time" are grouped into "Long-lived Se= ssions Group". New timer called "Long-lived Session Read Only Timer" is def= ined. >>> >>> >>> >>> >>> >>> Once the session is re-established, the procedures specified in >>> [RFC4724] >>> >>> >>> >>> apply for the stale routes irrespective of whether the stale routes >>> are retained during the"Restart Time" period or the "Long-lived Stale >>> Time" period except that such procedures are delayed for the peers >>> belonging to "Long-lived >>> >>> Sessions Group" till all members of the group send EOR message or the >>> >>> "Long-lived Session Read Only Timer" expires. >>> >>> >>> >>> >>> >>> The "Long-lived Session Read Only Timer" is started upon reestablishmen= t ofthe first session belonging to "Long-lived Sessions Group". >>> >>> >>> >>> However, in the case of consecutive restarts (i.e, the session goes >>> down >>> >>> >>> >>> before the EoR is received) the previously marked stale routes MUST >>> NOT >>> >>> >>> >>> be deleted before the timer for the "Long-lived Stale Time" expires. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Best regards, >>> >>> R. >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 4, 2014 at 9:45 PM, Paul Mattes wrote= : >>> >>> I have been doing some work on long-lived graceful restart (LLGR) and a= plausible failure scenario has come up in discussions here, which does not= appear to be covered, though it certainly seems to be the sort of failure = that should be addressed by LLGR. >>> >>> >>> >>> The scenario happens when we have LLGR configured on both sides of a >>> number of peering sessions, and BGP speaker (e.g., a Route Reflector) >>> loses contact with a number of its peers simultaneously. The likely >>> cause would be that the paths to the peers share a common element >>> that has failed. (And note that the common element could be part of >>> the BGP speaker in question - something that can be repaired without >>> restarting the system.) >>> >>> >>> >>> When contact with this set of peers is re-established, the scenario has= many of the same semantics of a restart. In particular, it would be best t= o delay sending End-of-RIB indications to any of the members of this set of= peers until End-Of-RIB to any of them, or until a reasonable timeout expir= es after the first comes back. Without this delay, the one BGP speaker woul= d likely send each of the peers a large number of advertisements with the L= LGR_STALE attribute (for the stale routes held for the other disconnected p= eers), followed by a large number of advertisements of the those same route= s without the LLGR_STALE attribute (as those routes are refreshed by the ot= her peers). There would likely be no change in reachability throughout the = network, but there could be a significant amount of FIB thrashing and trans= ient spikes in forwarding traffic, as well as a significant BGP-related I/O= and processing load on each of the speakers. >>> >>> >>> >>> While it seems like a restart, it is of course not a restart. And as fa= r as the peers which remain connected are concerned, it does not appear any= thing like a restart at all. >>> >>> >>> >>> While it is possible to imagine an implementation of LLGR that addresse= s this issue outside of the specification, I think it would be best if the = specification handled this scenario better, whether through a change in the= protocol or additional implementation advice. >>> >>> >>> >>> -- >>> >>> pdm >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >>> >> >> >> > > > From nobody Mon Apr 7 13:44:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3AA1A07B0 for ; Mon, 7 Apr 2014 13:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 d062TO6FocJy for ; Mon, 7 Apr 2014 13:44:07 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3020F1A02BF for ; Mon, 7 Apr 2014 13:44:07 -0700 (PDT) Received: from mail213-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.22; Mon, 7 Apr 2014 20:43:46 +0000 Received: from mail213-tx2 (localhost [127.0.0.1]) by mail213-tx2-R.bigfish.com (Postfix) with ESMTP id F201B9802AB; Mon, 7 Apr 2014 20:43:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371I542I1432Izz1f42h2148h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz8275ch1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h26d3h9a9j1155h) Received-SPF: pass (mail213-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=pmattes@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51704005)(24454002)(189002)(199002)(13464003)(47736001)(87266001)(81816001)(79102001)(85306002)(99396002)(19580405001)(76576001)(63696002)(20776003)(94946001)(90146001)(56816005)(94316002)(81686001)(76796001)(83322001)(4396001)(93516002)(85852003)(81542001)(53806001)(92566001)(76482001)(76786001)(56776001)(86362001)(77096001)(95666003)(80976001)(15975445006)(69226001)(74502001)(66066001)(65816001)(46102001)(47976001)(81342001)(59766001)(80022001)(97336001)(74316001)(47446002)(50986001)(74706001)(33646001)(87936001)(19580395003)(31966008)(74662001)(74366001)(98676001)(74876001)(83072002)(54356001)(49866001)(93136001)(54316002)(97186001)(77982001)(95416001)(2656002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB175; H:BY2PR05MB174.namprd05.prod.outlook.com; FPR:EE37F1E9.A4FA5F11.7BD33173.4EE8D150.207A8; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail213-tx2 (localhost.localdomain [127.0.0.1]) by mail213-tx2 (MessageSwitch) id 1396903423138899_28219; Mon, 7 Apr 2014 20:43:43 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.254]) by mail213-tx2.bigfish.com (Postfix) with ESMTP id 1E7F41C00FC; Mon, 7 Apr 2014 20:43:43 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 7 Apr 2014 20:43:43 +0000 Received: from BY2PR05MB175.namprd05.prod.outlook.com (10.242.39.156) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.435.0; Mon, 7 Apr 2014 20:43:56 +0000 Received: from BY2PR05MB174.namprd05.prod.outlook.com (10.242.39.150) by BY2PR05MB175.namprd05.prod.outlook.com (10.242.39.156) with Microsoft SMTP Server (TLS) id 15.0.908.10; Mon, 7 Apr 2014 20:43:54 +0000 Received: from BY2PR05MB174.namprd05.prod.outlook.com ([169.254.11.63]) by BY2PR05MB174.namprd05.prod.outlook.com ([169.254.11.180]) with mapi id 15.00.0898.005; Mon, 7 Apr 2014 20:43:53 +0000 From: Paul Mattes To: Robert Raszuk Thread-Topic: [Idr] Possible weakness in long-lived graceful restart Thread-Index: Ac9QO9JE+CyeW2xWRcmYZ+xCsyyfPwACSfEAAAMMYZAAAap3gAAAT6IgAADU4QAAj1nNUAAAq9gAAAFAtvA= Date: Mon, 7 Apr 2014 20:43:53 +0000 Message-ID: References: <2f22313a3a5c4c278e5517aca8463dba@BL2PR05MB161.namprd05.prod.outlook.com> <458f7a3d7c32425f99bac4cc0608d30c@BL2PR05MB161.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 0174BD4BDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/idr/iRVVjRXQ-yYD4kvoPG3vXDMaFuw Cc: "idr@ietf.org" Subject: Re: [Idr] Possible weakness in long-lived graceful restart X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 20:44:12 -0000 I agree that it should be optional. Implementing it would make you more nei= ghborly, but nothing in someone else's LLGR implementation would break if y= ou didn't. Now that we seem to have a viable solution, I will speak with John Scudder = about the possibility/likelihood/wisdom of getting it into a draft. -- pdm -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Monday, April 07, 2014 3:04 PM To: Paul Mattes Cc: idr@ietf.org Subject: Re: [Idr] Possible weakness in long-lived graceful restart Hi Paul, Yes you are correct. Now I guess if others agree that this is a valid problem to be solved we wo= uld need to update the draft with this additional procedure. As this is local optimization we can clearly make it optional to implement = so existing implementations do not need to worry about being not compliant = ;) Thx, R. On Mon, Apr 7, 2014 at 9:59 PM, Paul Mattes wrote: > Then what I missed was that the R would not advertise anything *to* A, B = or C until the Read-Only timer expired. Then I agree that A, B and C are li= kely to receive only one set of updates of one another's routes. Also route= rs D and E (other peers of R, not affected by the outage) would receive onl= y one set of updates for routes that originated from A, B and C. All good -= - thank you for your feedback and patience. > > -- > pdm > > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert=20 > Raszuk > Sent: Friday, April 04, 2014 6:20 PM > To: Paul Mattes > Cc: idr@ietf.org > Subject: Re: [Idr] Possible weakness in long-lived graceful restart > > Hi Paul, > > If A, B & C have not readvisrtised their non stale (any longer) paths to = R then R would not compute its best path (no trigger) and would not adverti= sed anything to them. > > Keep in mind that Read-Only mode is called such for a reason .. there is = no advertisement done during that time to peers in such RO mode. > Here we are just creating a new group and applying new timer .. but the b= asic behavior stays as it is today. > > Cheers, > R. > > > > > > > On Sat, Apr 5, 2014 at 1:07 AM, Paul Mattes wrote: >> Then I'm definitely missing something. But it wouldn't be the first=20 >> time. ;-) >> >> Let's call the router implementing this new timer R, and the other route= rs A, B and C. >> >> (1) R loses contact with A, B and C. >> (2) The outage lasts long enough for R to go into LLGR helper mode for e= ach. >> (3) R puts A, B and C into a group. >> >> At this point, the best paths for some number of routes in R's RIB came = from A, B or C. So it marks them with LLGR_STALE. >> >> (4) A reconnects. >> (5) R starts the Read-Only timer. >> (6) B and C reconnect. >> >> At this point, A, B and C have not re-advertised anything to R. >> >> (7) R advertises what it has to A, B and C. That includes the LLGR_STALE= routes mentioned above. >> >> (8) A, B and C re-advertise their routes. The Read-Only timer prevents t= hese routes from being use for best path computations, so nothing is re-adv= ertised. >> (9) A, B and C send End-of-RIB. >> (10) R runs best path on any routes that A, B or C refreshed. >> (11) R re-advertises any routes whose best path has now changed, or that= now have the LLGR_STALE community removed because they were refreshed. >> >> So I think the point of confusion is step (7), where R sends its current= RIB to the peers, which would include stale routes from B and C sent to A,= stale routes from A and C sent to B, and stale routes from A and B sent to= C. Or is something keeping R from doing that? >> >> -- >> pdm >> >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of=20 >> Robert Raszuk >> Sent: Friday, April 04, 2014 5:47 PM >> To: Paul Mattes >> Cc: idr@ietf.org >> Subject: Re: [Idr] Possible weakness in long-lived graceful restart >> >> Hi Paul, >> >> I actually do not see why you envision double advertisements. >> >> The amount of advertisement depends on two factors: >> >> - Duration of "Long-lived Session Read Only Timer" - if this is long eno= ugh and all peers in the LLGR-stale group would manage to restart - overall= best path would be send. We do need this timer not to wait forever for EOR= from each member of this group. >> >> - The fact that some peers will restart later then "Long-lived Session R= ead Only Timer" does not really mean that you will see full table again in = all peers. Only if such peers paths would become best you will see the path= s re-advertised .. so likely it would be small delta of overall number of p= aths. >> >>> But the best case, and I think the typical case with the read-only=20 >>> timer, would also be double advertisements of each route - once with=20 >>> LLGR_STALE attached, and once without it. >>> >>> Can we do better still? My hope is to avoid sending out that first=20 >>> wave of LLGR_STALE routes, too, if we can. Or am I misunderstanding=20 >>> how your mechanism would work? >> >> If you are talking after restart then not really. Those restarted and se= lected as best would be advertised when "Long-lived Session Read Only Timer= " without the STALE mark. >> >> If you are referring to original advertisement when sessions go down=20 >> then again .. unless there is no other best only then they will be=20 >> advertised with such MARK, but this is what this entire persistence=20 >> is all about after all :) >> >> Please let me know if you have any questions ... >> >> Cheers, >> R. >> >> On Sat, Apr 5, 2014 at 12:26 AM, Paul Mattes wrote= : >>> >>> I agree that my original suggestion of just suppressing End-of-RIB woul= dn't help much with the thrashing. So this appears less like a partial-rest= art scenario than I had thought. >>> >>> >>> >>> I see that your solution could avoid a lot thrashing. The router implem= enting this procedure would still initially advertise its stale RIB (some r= outes LLGR-stale, some not) to each of the newly-re-established peers, and = send End-of-RIB. The new timer would prevent it from advertising intermedia= te states for routes from the group, until each of the peers has sent End-o= f-RIB. Then it would re-advertise whichever routes are now best, looking li= ke something close to the last state they were advertised in before the dis= aster. The worst case for this is advertising every route from the group tw= ice, which is much better than the existing worst case, which is (I think) = advertising every route N times, where N is the number of peers that discon= nected. >>> >>> >>> >>> But the best case, and I think the typical case with the read-only time= r, would also be double advertisements of each route - once with LLGR_STALE= attached, and once without it. >>> >>> >>> >>> Can we do better still? My hope is to avoid sending out that first wave= of LLGR_STALE routes, too, if we can. Or am I misunderstanding how your me= chanism would work? >>> >>> >>> >>> -- >>> >>> pdm >>> >>> >>> >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of=20 >>> Robert Raszuk >>> Sent: Friday, April 04, 2014 3:32 PM >>> To: Paul Mattes >>> Cc: idr@ietf.org >>> Subject: Re: [Idr] Possible weakness in long-lived graceful restart >>> >>> >>> >>> Hi Paul, >>> >>> >>> >>> I think your observation is valid and possible in real deployments howe= ver the fix you are asking for may be slightly. >>> >>> >>> >>> First let's observe that "Restart Time" and "Long lived Stale Time" is = per session and defined procedures are also per session. >>> >>> >>> >>> To apply any solution it would be required to find a way to dynamically= group peers which may belong to the same "peer failure risk group", but th= at is hard as IBGP sessions to those peers naturally are designed to work a= round single network failures. >>> >>> >>> >>> An option could be perhaps to treat all peers running in under "Long li= ved Stale Time" state as one group and then define a "Long Lived Read Only = Timer" which would start from the first session previously in such group to= get re-established and till it expires suppress any best path computation = based on the newly received paths from those peers. >>> >>> >>> >>> Literally what you are pointing out could be fixed by the following tex= t addition to "draft-uttaro-idr-bgp-persistence-03" section 4.2: >>> >>> >>> >>> Current text: >>> >>> >>> >>> >>> >>> Once the session is re-established, the procedures specified in [RFC472= 4] apply for the stale routes irrespective of whether the stale routes are = retained during the"Restart Time" period or the "Long-lived Stale Time" per= iod. >>> >>> However, in the case of consecutive restarts (i.e,the session goes down= before the EoR is received) the previously marked stale routes MUST NOT be= deleted before the timer for the "Long-lived Stale Time" expires. >>> >>> >>> >>> New text: >>> >>> >>> >>> All sessions in "Long-lived Stale Time" are grouped into "Long-lived Se= ssions Group". New timer called "Long-lived Session Read Only Timer" is def= ined. >>> >>> >>> >>> >>> >>> Once the session is re-established, the procedures specified in=20 >>> [RFC4724] >>> >>> >>> >>> apply for the stale routes irrespective of whether the stale routes=20 >>> are retained during the"Restart Time" period or the "Long-lived=20 >>> Stale Time" period except that such procedures are delayed for the=20 >>> peers belonging to "Long-lived >>> >>> Sessions Group" till all members of the group send EOR message or=20 >>> the >>> >>> "Long-lived Session Read Only Timer" expires. >>> >>> >>> >>> >>> >>> The "Long-lived Session Read Only Timer" is started upon reestablishmen= t ofthe first session belonging to "Long-lived Sessions Group". >>> >>> >>> >>> However, in the case of consecutive restarts (i.e, the session goes=20 >>> down >>> >>> >>> >>> before the EoR is received) the previously marked stale routes MUST=20 >>> NOT >>> >>> >>> >>> be deleted before the timer for the "Long-lived Stale Time" expires. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Best regards, >>> >>> R. >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 4, 2014 at 9:45 PM, Paul Mattes wrote= : >>> >>> I have been doing some work on long-lived graceful restart (LLGR) and a= plausible failure scenario has come up in discussions here, which does not= appear to be covered, though it certainly seems to be the sort of failure = that should be addressed by LLGR. >>> >>> >>> >>> The scenario happens when we have LLGR configured on both sides of a=20 >>> number of peering sessions, and BGP speaker (e.g., a Route=20 >>> Reflector) loses contact with a number of its peers simultaneously.=20 >>> The likely cause would be that the paths to the peers share a common=20 >>> element that has failed. (And note that the common element could be=20 >>> part of the BGP speaker in question - something that can be repaired=20 >>> without restarting the system.) >>> >>> >>> >>> When contact with this set of peers is re-established, the scenario has= many of the same semantics of a restart. In particular, it would be best t= o delay sending End-of-RIB indications to any of the members of this set of= peers until End-Of-RIB to any of them, or until a reasonable timeout expir= es after the first comes back. Without this delay, the one BGP speaker woul= d likely send each of the peers a large number of advertisements with the L= LGR_STALE attribute (for the stale routes held for the other disconnected p= eers), followed by a large number of advertisements of the those same route= s without the LLGR_STALE attribute (as those routes are refreshed by the ot= her peers). There would likely be no change in reachability throughout the = network, but there could be a significant amount of FIB thrashing and trans= ient spikes in forwarding traffic, as well as a significant BGP-related I/O= and processing load on each of the speakers. >>> >>> >>> >>> While it seems like a restart, it is of course not a restart. And as fa= r as the peers which remain connected are concerned, it does not appear any= thing like a restart at all. >>> >>> >>> >>> While it is possible to imagine an implementation of LLGR that addresse= s this issue outside of the specification, I think it would be best if the = specification handled this scenario better, whether through a change in the= protocol or additional implementation advice. >>> >>> >>> >>> -- >>> >>> pdm >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>> >>> >> >> >> > > > From nobody Tue Apr 8 07:11:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E729A1A0417; Tue, 8 Apr 2014 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 lDNsMyl1R22Q; Tue, 8 Apr 2014 07:11:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1794D1A03FB; Tue, 8 Apr 2014 07:11:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140408141148.11589.47865.idtracker@ietfa.amsl.com> Date: Tue, 08 Apr 2014 07:11:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/qBvhg_KnoiQQgsL5cJsteyf0kx8 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aigp-17.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:11:53 -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 Working Group of the IETF. Title : The Accumulated IGP Metric Attribute for BGP Authors : Pradosh Mohapatra Rex Fernando Eric C. Rosen James Uttaro Filename : draft-ietf-idr-aigp-17.txt Pages : 15 Date : 2014-04-08 Abstract: Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-aigp-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-aigp-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 8 14:25:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1131A074E; Tue, 8 Apr 2014 14:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 98y3w2oclXMQ; Tue, 8 Apr 2014 14:25:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B90C1A0203; Tue, 8 Apr 2014 14:25:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140408212530.6885.97567.idtracker@ietfa.amsl.com> Date: Tue, 08 Apr 2014 14:25:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/bNNhU_4MhCSqSB8v5MKAbK1JhHI Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 21:25:31 -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 Working Group of the IETF. Title : Reservation of Last Autonomous System (AS) Numbers Authors : Jeffrey Haas Jon Mitchell Filename : draft-ietf-idr-last-as-reservation-05.txt Pages : 5 Date : 2014-04-08 Abstract: This document reserves two Autonomous System numbers (ASNs) at the end of the 16 bit and 32 bit ranges, described in this document as "Last ASNs" and provides guidance to implementers and operators on their use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-last-as-reservation-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 Apr 9 13:30:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C75F1A02E2; Wed, 9 Apr 2014 13:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 XGPoe9Xf2pc1; Wed, 9 Apr 2014 13:30:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 970051A024F; Wed, 9 Apr 2014 13:30:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140409203030.31563.36107.idtracker@ietfa.amsl.com> Date: Wed, 09 Apr 2014 13:30:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/oWd7vDqZMtSSmWF3qro6L-SWE4o Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-legacy-rtc-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 20:30:31 -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 Working Group of the IETF. Title : Automatic Route Target Filtering for legacy PEs Authors : Pradosh Mohapatra Arjun Sreekantiah Keyur Patel Burjiz Pithawala Alton Lo Filename : draft-ietf-idr-legacy-rtc-03.txt Pages : 10 Date : 2014-02-13 Abstract: This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in [RFC4684]. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace [RFC4684]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-legacy-rtc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-legacy-rtc-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-legacy-rtc-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 Thu Apr 10 07:56:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C773B1A030B; Thu, 10 Apr 2014 07:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.732 X-Spam-Level: ** X-Spam-Status: No, score=2.732 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=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 c6ALkcm5elAS; Thu, 10 Apr 2014 07:55:57 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) by ietfa.amsl.com (Postfix) with ESMTP id B87051A0306; Thu, 10 Apr 2014 07:55:56 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-aigp-17.txt Thread-Index: AQHPUzSObjQ+iElOPE2D50DM0rqltpsK2GNg Date: Thu, 10 Apr 2014 14:55:54 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011E388A@EX01.swan.local> References: <20140408141148.11589.47865.idtracker@ietfa.amsl.com> In-Reply-To: <20140408141148.11589.47865.idtracker@ietfa.amsl.com> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.40.93] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/SHpAfGIXPrZwwKTSKJac4THeRhw Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-aigp-17.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 14:55:59 -0000 Hello everybody,=20 I would like to clarify my understanding on couple of the points below. I'm= sorry if I query about something that has been discussed already.=20 Thank you very much for your time. 3.4.1. Originating the AIGP Attribute.=20 A BGP speaker MUST NOT add the AIGP attribute to any route whose path leads= outside the "AIGP administrative domain" to which the BGP speaker belongs.= =20 The route is an EBGP-learned route whose AS_PATH contains only ASes that ar= e in the same AIGP Administrative Domain as the BGP speaker.=20 - Wouldn't it be helpful to use AIGP metric to find best exit(s) from an ad= ministrative domain please?=20 3.4.1. Originating the AIGP Attribute.=20 When a BGP speaker R is redistributing into BGP an IGP route to address pre= fix P, the IGP will have computed a "distance" from R to P. This distance = MAY be assigned as the value of the AIGP TLV.=20 - So with AIGP, e.g CEs connected to MPSL backbone would be able to make th= e routing decisions based on the whole CE to CE path and that is regardless= of the CE to PE routing protocol.=20 - Do I understand it correctly please?=20 3.4.3. Modifications by a Non-Originator.=20 Suppose R1 changes the Next Hop of the route from R2 to R1, and R1's route = to R2 is either (a) a BGP-learned route or (b) a static route that requires= recursive next hop resolution.=20 - I'd like to clarify my understanding of this section please.=20 - Do I understand it correctly that this section is concerning the case of = Hierarchical MPLS for InterAS MPLS VPN Opt.10C or CsC with use of RFC3107 p= lease?=20 - In other words case where the NH for a VPN prefix (egress PE BGP RID) is = known via BGP from ASBR -and path to that NH is recursively found via IGP p= ath to ASBR.=20 - So in this case the AIGP metric to NH would be a sum of AIGP metric adver= tised by the ASBR and the IGP metric to that ASBR.=20 - However if VPNv4/v6 session carries AIGP metric from CE to CE -the AIGP m= etric might consist of the AIGP metric between ingress and egress PEs and t= he AIGP metric derived from the IGP distance from PE to CE.=20 4. Decision Process.=20 The procedures in this section MUST be executed BEFORE any of the tie break= ing procedures described in [BGP] section 9.1.2.2 are executed.=20 - So for routes with AIGP TLV, AIGP metric is considered first (so BGP basi= cally becomes RIP) and only if there is a tie the regular BGP decision proc= ess is invoked afterwards.=20 - Do I understand it correctly please?=20 4.2. When the Route to the Next Hop has an AIGP attribute.=20 - In hierarchical MPLS it would be great if we could chose based either on = the whole: local igp metric to ASBR-NH + AIGP metric or just based on AIGP = itself ignoring the local igp metric to ASBR-NH "sort of" OSPF's E1 to E2.= =20 adam From nobody Thu Apr 17 08:14:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3698C1A013A; Thu, 17 Apr 2014 08:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 VtZ5kFFa69T5; Thu, 17 Apr 2014 08:14:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5134E1A0138; Thu, 17 Apr 2014 08:14:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140417151427.4674.80841.idtracker@ietfa.amsl.com> Date: Thu, 17 Apr 2014 08:14:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/gybovlxPCLLNRUmE3svw7Nd8960 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-redirect-ip-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 15:14: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 Working Group of the IETF. Title : BGP Flow-Spec Redirect to IP Action Authors : James Uttaro Jeffrey Haas Matthieu Texier Andy Karch Adam Simpson Wim Henderickx Filename : draft-ietf-idr-flowspec-redirect-ip-01.txt Pages : 8 Date : 2014-04-17 Abstract: Flow-spec 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 [RFC 5575] defines a redirect-to-VRF action for policy-based forwarding but this mechanism can be difficult to use, particularly in networks without L3 VPN infrastructure. This draft defines a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. The details of the action, including the IPv4 or IPv6 target address, are encoded in newly defined BGP extended communities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-ip/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-ip-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-redirect-ip-01 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 Apr 17 10:59:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAE81A0640 for ; Tue, 15 Apr 2014 07:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 7c6x-Fsieljv for ; Tue, 15 Apr 2014 07:36:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 9F60D1A074A for ; Tue, 15 Apr 2014 07:36:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8E1591801A3; Tue, 15 Apr 2014 07:36:18 -0700 (PDT) To: curtis@ans.net, rchandra@cisco.com, govindan@isi.edu, akatlas@gmail.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140415143618.8E1591801A3@rfc-editor.org> Date: Tue, 15 Apr 2014 07:36:18 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/sB83D6Fwrvq_Sz_etUowAmJOtHk X-Mailman-Approved-At: Thu, 17 Apr 2014 10:59:38 -0700 Cc: guban@microsoft.com, rfc-editor@rfc-editor.org, idr@ietf.org Subject: [Idr] [Technical Errata Reported] RFC2439 (3964) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 14:36:49 -0000 The following errata report has been submitted for RFC2439, "BGP Route Flap Damping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2439&eid=3964 -------------------------------------- Type: Technical Reported by: Gunjan Bansal Section: 4.8.2 Original Text ------------- In either case then: 1. set t-updated = t-now 2. insert into a reuse list (see Section 4.8.6) Corrected Text -------------- In either case then: 1. set t-updated = t-now Notes ----- The route which is unreachable should NOT be inserted into the reuse-list. reuse-list (as per explanation in Section 4.8.7) is used for fast evaluation of routes which have been suppressed long enough and can be potentially used again. The "unreachability/withdrawal" of route is never suppressed and never needs to be re-evaluated in future. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2439 (no draft string recorded) -------------------------------------- Title : BGP Route Flap Damping Publication Date : November 1998 Author(s) : C. Villamizar, R. Chandra, R. Govindan Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 18 08:28:19 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C401A03CC for ; Fri, 18 Apr 2014 08:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 nfJGMAYOOnFb for ; Fri, 18 Apr 2014 08:28:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4A51A0256 for ; Fri, 18 Apr 2014 08:28:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B5DC1C2D8; Fri, 18 Apr 2014 11:28:12 -0400 (EDT) Date: Fri, 18 Apr 2014 11:28:12 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20140418152812.GG29430@pfrc> 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: http://mailarchive.ietf.org/arch/msg/idr/zWAh-2QBF7o4LkKW9Rgx6n0lvhg Subject: [Idr] [internet-drafts@ietf.org: I-D Action: draft-ietf-idr-flowspec-redirect-ip-01.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 15:28:18 -0000 IDR, The authors were kind enough to address my original concerns about the use of the nexthop field in this draft and move to the use of extended communities to contain the redirection address. (And also added me to the author list so I'd have to own up to any negative comments about that. :-) One of the details that still requires some refinement in the draft have to do with the presence of multiple actions that may impact forwarding. These include the original redirect-to-vrf, redirect-to-ip, copy. There is an attempt to set some precedence for these operations in cases where an implementation is unable to support more than one action. There is also also an attempt to describe how a mixture of forwarding operations may work in implementations that might support some forms of load balancing. Regardless of your opinions on these topics, please remember that something that must be dealt with in the design of the feature is that since these features are implemented as communities, there may be more than one type present. Since the addition or deletion of such communities may be done at a router that is not the flowspec route originator, Do Something Sane is the order of the day. We look forward to your suggestions and comments. -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- Date: Thu, 17 Apr 2014 08:14:27 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: I-D Action: draft-ietf-idr-flowspec-redirect-ip-01.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 Working Group of the IETF. Title : BGP Flow-Spec Redirect to IP Action Authors : James Uttaro Jeffrey Haas Matthieu Texier Andy Karch Adam Simpson Wim Henderickx Filename : draft-ietf-idr-flowspec-redirect-ip-01.txt Pages : 8 Date : 2014-04-17 Abstract: Flow-spec 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 [RFC 5575] defines a redirect-to-VRF action for policy-based forwarding but this mechanism can be difficult to use, particularly in networks without L3 VPN infrastructure. This draft defines a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. The details of the action, including the IPv4 or IPv6 target address, are encoded in newly defined BGP extended communities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-ip/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-ip-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-redirect-ip-01 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- From nobody Mon Apr 21 13:01:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE43B1A0281 for ; Mon, 21 Apr 2014 13:01:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 w8ue-zG1QpRg for ; Mon, 21 Apr 2014 13:01:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) by ietfa.amsl.com (Postfix) with ESMTP id C01A51A0277 for ; Mon, 21 Apr 2014 13:01:36 -0700 (PDT) Received: from [172.29.35.62] (66.129.241.18) by CO2PR05MB732.namprd05.prod.outlook.com (10.141.228.22) with Microsoft SMTP Server (TLS) id 15.0.918.8; Mon, 21 Apr 2014 20:01:30 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Apr 2014 16:01:19 -0400 Message-ID: To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.18] X-ClientProxiedBy: BL2PR08CA0024.namprd08.prod.outlook.com (10.255.170.142) To CO2PR05MB732.namprd05.prod.outlook.com (10.141.228.22) X-Forefront-PRVS: 0188D66E61 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(6049001)(428001)(164054003)(199002)(189002)(87976001)(89996001)(47776003)(88136002)(85852003)(87286001)(74502001)(83072002)(77982001)(20776003)(66066001)(50466002)(92566001)(86362001)(92726001)(83716003)(93916002)(4396001)(31966008)(74662001)(50986999)(19580395003)(99396002)(46406003)(97756001)(83322001)(79102001)(80976001)(50226001)(81542001)(42186004)(23726002)(81342001)(15975445006)(33656001)(62966002)(558084003)(76482001)(57306001)(82746002)(80022001)(46102001)(36756003)(77156001)(15202345003)(42262001)(15302535010); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB732; H:[172.29.35.62]; FPR:FFA1CA79.BCF207EB.414336BC.D8C157F9.20093; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ADLR2DHHV0mCuy3fVApVyrA8M2o Cc: draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org Subject: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 20:01:38 -0000 Folks, We have received a request for a working group last call on = draft-ietf-idr-flowspec-redirect-rt-bis-00. A URL for the draft is = http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-00 Please send comments to the list by May 6. Thanks, --John= From nobody Thu Apr 24 06:05:30 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B341A01E2; Thu, 24 Apr 2014 06:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 jf--hjTd7HTk; Thu, 24 Apr 2014 06:05:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 553821A01B3; Thu, 24 Apr 2014 06:05:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424130523.4556.41274.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 06:05:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/sGPALrXoF35-yiJKsaKVA6WUx_M Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 13:05:25 -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 Working Group of the IETF. Title : Reservation of Last Autonomous System (AS) Numbers Authors : Jeffrey Haas Jon Mitchell Filename : draft-ietf-idr-last-as-reservation-06.txt Pages : 5 Date : 2014-04-24 Abstract: This document reserves two Autonomous System numbers (ASNs) at the end of the 16 bit and 32 bit ranges, described in this document as "Last ASNs" and provides guidance to implementers and operators on their use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-last-as-reservation-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 28 06:44:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D491A0A20 for ; Mon, 28 Apr 2014 06:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 487ynxzpHMix for ; Mon, 28 Apr 2014 06:44:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 00C571A0A1D for ; Mon, 28 Apr 2014 06:44:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 501E6C12C; Mon, 28 Apr 2014 09:44:44 -0400 (EDT) Date: Mon, 28 Apr 2014 09:44:44 -0400 From: Jeffrey Haas To: "John G. Scudder" Message-ID: <20140428134444.GA1256@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/yPGt0purOwXeXhWzf12F2YH_d1Q Cc: "idr@ietf. org" , draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 13:44:46 -0000 On Mon, Apr 21, 2014 at 04:01:19PM -0400, John G. Scudder wrote: > Folks, > > We have received a request for a working group last call on draft-ietf-idr-flowspec-redirect-rt-bis-00. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-00 > > Please send comments to the list by May 6. And given that the scope of the draft is very narrow, it should be a quick read-through for people. :-) -- Jeff (trying to interrupt the crickets chirping) From nobody Mon Apr 28 07:03:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986F91A0A19; Mon, 28 Apr 2014 07:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1E347xlgWcPK; Mon, 28 Apr 2014 07:03:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBBC1A0A0E; Mon, 28 Apr 2014 07:03:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428140330.7178.39512.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 07:03:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/72U_bqwzwBLZ2CYoOBYeaNpRz_0 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aigp-18.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 14:03:31 -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 Working Group of the IETF. Title : The Accumulated IGP Metric Attribute for BGP Authors : Pradosh Mohapatra Rex Fernando Eric C. Rosen James Uttaro Filename : draft-ietf-idr-aigp-18.txt Pages : 15 Date : 2014-04-28 Abstract: Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-aigp-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-aigp-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 28 08:05:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F1E1A0A70 for ; Mon, 28 Apr 2014 08:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 OhVR3AqmB1-j for ; Mon, 28 Apr 2014 08:05:14 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E45C91A0A18 for ; Mon, 28 Apr 2014 08:05:08 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B31E8C94C0; Mon, 28 Apr 2014 11:05:05 -0400 (EDT) Date: Mon, 28 Apr 2014 11:05:05 -0400 From: John Leslie To: Jeffrey Haas Message-ID: <20140428150505.GA94140@verdi> References: <20140428134444.GA1256@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140428134444.GA1256@pfrc> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/idr/bBh_70HX6pG_ktc9fNGZzb3z13Q Cc: draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org, "idr@ietf. org" Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 15:05:20 -0000 Jeffrey Haas wrote: > > And given that the scope of the draft is very narrow, it should be a quick > read-through for people. :-) Quick read, yes. Quick comprehension, no. :^( I searched for the registries IANA is asked to update; and didn't find them. Can we save the cycles of IANA at IETF LastCall to say they can't find them either? -- John Leslie From nobody Mon Apr 28 08:52:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883C81A07A6 for ; Mon, 28 Apr 2014 08:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 JjuVm7qiJKbC for ; Mon, 28 Apr 2014 08:52:10 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 839051A09EE for ; Mon, 28 Apr 2014 08:52:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BF46FC12C; Mon, 28 Apr 2014 11:52:09 -0400 (EDT) Date: Mon, 28 Apr 2014 11:52:09 -0400 From: Jeffrey Haas To: John Leslie Message-ID: <20140428155209.GC1256@pfrc> References: <20140428134444.GA1256@pfrc> <20140428150505.GA94140@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140428150505.GA94140@verdi> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rUoQ77kw4UdVCniIByxkcpnvHgc Cc: draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org, "idr@ietf. org" Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 15:52:12 -0000 John, On Mon, Apr 28, 2014 at 11:05:05AM -0400, John Leslie wrote: > Jeffrey Haas wrote: > > And given that the scope of the draft is very narrow, it should be a quick > > read-through for people. :-) > > Quick read, yes. > > Quick comprehension, no. :^( > > I searched for the registries IANA is asked to update; and didn't > find them. This is mostly because the dependent change that re-organizes the IANA registries in question is finishing (has finished) IESG review. (c.f. http://tools.ietf.org/html/draft-ietf-idr-extcomm-iana-02) -- Jeff From nobody Mon Apr 28 10:26:54 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A5C1A6F8E for ; Mon, 28 Apr 2014 10:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 4rrW_cbJ4k7s for ; Mon, 28 Apr 2014 10:26:50 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C321D1A6F68 for ; Mon, 28 Apr 2014 10:26:50 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id D5043C94E5; Mon, 28 Apr 2014 13:26:47 -0400 (EDT) Date: Mon, 28 Apr 2014 13:26:47 -0400 From: John Leslie To: Jeffrey Haas Message-ID: <20140428172647.GB94140@verdi> References: <20140428134444.GA1256@pfrc> <20140428150505.GA94140@verdi> <20140428155209.GC1256@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140428155209.GC1256@pfrc> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jwlnxU13SkBQwiTBvj92TMSURMU Cc: draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org, Susan Hares , "idr@ietf. org" Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 17:26:52 -0000 Jeffrey Haas wrote: > On Mon, Apr 28, 2014 at 11:05:05AM -0400, John Leslie wrote: > >> I searched for the registries IANA is asked to update; and didn't >> find them. > > This is mostly because the dependent change that re-organizes the IANA > registries in question is finishing (has finished) IESG review. > (c.f. http://tools.ietf.org/html/draft-ietf-idr-extcomm-iana-02) Believe it or not, I haven't memorized every draft that went through an IESG telechat... ;^) But I see that it went through on January 9, and has become RFC 7153 (announced March 14). This makes me wonder why its changes appear not to have showed up on the IANA.org site. I see Sue was Document Shepherd -- can she shed any light on this? -- John Leslie From nobody Mon Apr 28 10:30:42 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282211A6FA1 for ; Mon, 28 Apr 2014 10:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 sMgZfS0lGv2p for ; Mon, 28 Apr 2014 10:30:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 47D4A1A6F8E for ; Mon, 28 Apr 2014 10:30:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 75527C12C; Mon, 28 Apr 2014 13:30:36 -0400 (EDT) Date: Mon, 28 Apr 2014 13:30:36 -0400 From: Jeffrey Haas To: John Leslie Message-ID: <20140428173036.GD1256@pfrc> References: <20140428134444.GA1256@pfrc> <20140428150505.GA94140@verdi> <20140428155209.GC1256@pfrc> <20140428172647.GB94140@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140428172647.GB94140@verdi> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/UNswb2bZLvi-MzGjHZLg_g8YfsE Cc: draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org, Susan Hares , "idr@ietf. org" Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 17:30:42 -0000 On Mon, Apr 28, 2014 at 01:26:47PM -0400, John Leslie wrote: > Believe it or not, I haven't memorized every draft that went through > an IESG telechat... ;^) And I had no expectation of it. :-) > But I see that it went through on January 9, and has become RFC 7153 > (announced March 14). Thanks for pointing that out. I'll update the draft. > This makes me wonder why its changes appear not to have showed up > on the IANA.org site. I see Sue was Document Shepherd -- can she shed > any light on this? I'm also unclear on the lag-time to implement this at IANA. Unlike other efforts, this is a bit of a rewrite for them so may take a bit of time. -- Jeff From nobody Mon Apr 28 13:36:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F8A1A6FEE for ; Mon, 28 Apr 2014 13:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 gn_nf705n3Qc for ; Mon, 28 Apr 2014 13:36:30 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9141A064C for ; Mon, 28 Apr 2014 13:36:30 -0700 (PDT) Received: from choy-sslvpn-nc.jnpr.net (66.129.241.13) by BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) with Microsoft SMTP Server (TLS) id 15.0.929.12; Mon, 28 Apr 2014 20:36:28 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <496EB0F5-96D9-4ACA-8BC5-CDC39B27C1C6@juniper.net> Date: Mon, 28 Apr 2014 16:36:19 -0400 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BLUPR08CA021.namprd08.prod.outlook.com (10.141.240.41) To BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) X-Forefront-PRVS: 01952C6E96 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(164054003)(20776003)(77156001)(87976001)(88136002)(36756003)(53416003)(558084003)(83322001)(80976001)(82746002)(33656001)(2009001)(97756001)(50986999)(79102001)(99396002)(83716003)(87286001)(62966002)(47776003)(80022001)(66066001)(81342001)(50466002)(81542001)(92726001)(46102001)(93916002)(86362001)(92566001)(42186004)(76482001)(100916002)(50226001)(4396001)(31966008)(23726002)(74502001)(77982001)(89996001)(57306001)(46406003)(101416001)(74662001)(100906001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB724; H:choy-sslvpn-nc.jnpr.net; FPR:775244DB.895224FB.416EF0B6.84C1DFDD.2008D; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/578QSCinbYt6g27d872JOt8k3pU Subject: [Idr] Early allocation request for draft-ietf-idr-bgp-gr-notification-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:36:33 -0000 Folks, The chairs have received a request to allocate a Cease subcode for = draft-ietf-idr-bgp-gr-notification-01 per RFC 7120. If anyone has any = objection please send it by May 5. Thanks, --John= From nobody Mon Apr 28 13:56:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B13C1A6FB7 for ; Mon, 28 Apr 2014 13:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=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 Evb85A3AERbj for ; Mon, 28 Apr 2014 13:56:12 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7083E1A6FEE for ; Mon, 28 Apr 2014 13:56:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'John G. Scudder'" , "'idr@ietf. org'" Date: Mon, 28 Apr 2014 16:56:08 -0400 Message-ID: <013001cf6324$47e64700$d7b2d500$@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: Ac9jI/ZUR8t1VNDKRqmaTo0qKuQu1Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HPeerJfBbSRD_Jwzv49CvNDUbqo Subject: [Idr] Early allocation request and WGL LC for draft-ietf-idr-bgp-gr-notification-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:56:13 -0000 Folks, Oops.. please revise the last message to: The chairs have received a request to do a WG LC for the draft-ietf-idr-bgp-gr-notification-01 and to allocate a Cease subcode for draft-ietf-idr-bgp-gr-notification-01 per RFC 7120. Please send any objections for early allocation and comments on WG LC include support/no-support. This call ends on 5/12. Sue and John From nobody Mon Apr 28 14:17:35 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCEB1A7030 for ; Mon, 28 Apr 2014 14:17:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Su1jo54RoFf9 for ; Mon, 28 Apr 2014 14:17:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC4C1A07A2 for ; Mon, 28 Apr 2014 14:17:28 -0700 (PDT) Received: from choy-sslvpn-nc.jnpr.net (66.129.241.18) by BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) with Microsoft SMTP Server (TLS) id 15.0.929.12; Mon, 28 Apr 2014 21:17:26 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <013001cf6324$47e64700$d7b2d500$@ndzh.com> Date: Mon, 28 Apr 2014 17:17:16 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <6CFB938D-E566-40C1-B3FB-6900CEE2B7D3@juniper.net> References: <013001cf6324$47e64700$d7b2d500$@ndzh.com> To: Hares Susan X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.18] X-ClientProxiedBy: BY2PR02CA018.namprd02.prod.outlook.com (10.242.234.146) To BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) X-Forefront-PRVS: 01952C6E96 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(199002)(189002)(377454003)(24454002)(50226001)(76482001)(100916002)(92726001)(46102001)(86362001)(93916002)(92566001)(42186004)(46406003)(57306001)(74662001)(101416001)(31966008)(23726002)(4396001)(74502001)(77982001)(89996001)(36756003)(53416003)(88136002)(19580405001)(80976001)(19580395003)(83322001)(77156001)(87976001)(20776003)(82746002)(83716003)(87286001)(47776003)(62966002)(99396002)(81542001)(50466002)(80022001)(81342001)(66066001)(2009001)(97756001)(33656001)(76176999)(79102001)(50986999)(100906001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB724; H:choy-sslvpn-nc.jnpr.net; FPR:FC92C5DE.8D961FA9.31E9B336.8CC2DD2C.2016F; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jX9hORMYxoTYXDe2T4vR-qk-Axk Cc: "idr@ietf. org" Subject: Re: [Idr] Early allocation request and WGL LC for draft-ietf-idr-bgp-gr-notification-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:17:31 -0000 All, Sorry for the rapid iteration here but: There will soon be a -02 of = gr-notification with some minor updates; I would suggest holding your = WGLC review until then. We'll notify the list again when ready. --John On Apr 28, 2014, at 4:56 PM, Susan Hares wrote: > Folks, >=20 > Oops.. please revise the last message to:=20 >=20 > The chairs have received a request to do a WG LC for the > draft-ietf-idr-bgp-gr-notification-01 and to allocate a Cease subcode = for > draft-ietf-idr-bgp-gr-notification-01 per RFC 7120.=20 >=20 > Please send any objections for early allocation and comments on WG LC > include support/no-support.=20 >=20 > This call ends on 5/12.=20 >=20 > Sue and John=20 >=20 >=20 From nobody Wed Apr 30 00:33:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A341A1A6EF4; Wed, 30 Apr 2014 00:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1CIsGFoWwIqG; Wed, 30 Apr 2014 00:33:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 120201A015F; Wed, 30 Apr 2014 00:33:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140430073322.25978.62117.idtracker@ietfa.amsl.com> Date: Wed, 30 Apr 2014 00:33:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HqHRNt7nFcrqQIcA_Krf7q8t_50 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 07:33: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 Working Group of the IETF. Title : Inter-domain SLA Exchange Authors : Shitanshu Shah Keyur Patel Sandeep Bajaj Luis Tomotaki Mohamed Boucadair Filename : draft-ietf-idr-sla-exchange-03.txt Pages : 24 Date : 2014-04-30 Abstract: Network administrators typically enforce Quality of Service (QoS) policies according to Service Level Agreement (SLA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, many times manual, process and prone to errors. This document proposes an in-band method of SLA signaling which can help to simplify some of the complexities. This document defines an optional transitive attribute to signal SLA details in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplifying and facilitating some of the complex provisioning tasks. Though the use case with the proposed BGP attribute is explicitly defined in this document, purpose of this attribute is not limited to this use case only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-sla-exchange-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/