From chris.hall@highwayman.com Tue Jan 1 09:27:58 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD0E21E8041; Tue, 1 Jan 2013 09:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.156 X-Spam-Level: X-Spam-Status: No, score=0.156 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t57VC4LCu17R; Tue, 1 Jan 2013 09:27:57 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta004.mxout.tch.inty.net [91.221.169.45]) by ietfa.amsl.com (Postfix) with ESMTP id A5BF221E803F; Tue, 1 Jan 2013 09:27:56 -0800 (PST) Received: from mdfmta004.tch.inty.net (unknown [127.0.0.1]) by mdfmta004.tch.inty.net (Postfix) with ESMTP id 3C8BFAC43CD; Tue, 1 Jan 2013 17:27:55 +0000 (GMT) Received: from mdfmta004.tch.inty.net (unknown [127.0.0.1]) by mdfmta004.tch.inty.net (Postfix) with ESMTP id 01EF9AC43CA; Tue, 1 Jan 2013 17:27:55 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta004.tch.inty.net (Postfix) with ESMTP; Tue, 1 Jan 2013 17:27:54 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Tq5d3-0000zw-Uz; Tue, 01 Jan 2013 17:27:54 +0000 From: "Chris Hall" To: , Date: Tue, 1 Jan 2013 17:27:48 -0000 Organization: Highwayman Message-ID: <03c501cde845$54f82b30$fee88190$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3oRU5I57qn1PrRSQSfRRimyGjioQ== Content-Language: en-gb X-MDF-HostID: 17 Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 17:27:58 -0000 Jeff Wheeler wrote (on Mon 31-Dec-2012 at 20:36 +0000): .... > Like I keep saying, the goal of error-handling should be to make > session-reset avoidable. Today it is not. It is creating complex > rules which must be supported by both sides of the BGP session to > try very hard to keep the network in a good state. It is a truth universally acknowledged (AFAICS), that if NLRI in a broken UPDATE are treated-as-withdraw, that is no worse than session-reset and much to be preferred. So, treat-as-withdraw is a reasonable thing for any implementation to do, by default, where it can. The problem is that when things are broken, it may not be possible to identify all the NLRI -- some may be "lost". [At this point I recommend: "The Engineer", AA Milne.] The effects of "lost NLRI" range from "ho hum" to "arghh", depending. The possibility of "lost NLRI" ranges from "small, I think" through "dunno" to "don't care". The incidence of "lost NLRI" can be reduced by some simple rule changes on the ordering of attributes. But, there is a desire to improve things without changes at the sender end. Also, there is a desire to avoid session-reset at (almost) all costs -- right up to the point where sessions are never reset (re-syncing on 16 x 0xFF as required). So, since we cannot eliminate "lost NLRI" let us learn to love them (or at least learn some tolerance). The risks posed by "lost NLRI" are unknown, and the effects context dependent. Given the uncertainty, I do not think it is reasonable to accept anything more than a (vanishingly) small risk of "lost NLRI", by default. So, AFAICS, we are in the land of the knob. Suppose three categories of error in an UPDATE message: * Non-Critical -- ie treat-as-withdraw or otherwise in general terms: all NLRI accounted for. More accurately: the risk of "lost NLRI" is deemed negligible. * Critical -- ie bad, but not session-reset in general terms: "lost NLRI", ie: either: there is reason to believe that there are "lost NLRI" (eg. a broken MP_UNREACH_NLRI attribute) or: it is not sufficiently clear that all NLRI are accounted for. NLRI that can be accounted for may be treated in a Non-Critical sort of a way, but some other response(s) may be triggered to mitigate the effect of "lost NLRI". * Fatal -- ie session-reset things are FUBAR -- by some definition. (Graceful Restart and enhancements thereof may blur the line between Fatal and Critical errors. But that's another story.) The message is broken... things are uncertain, so: a key knob is the one which allows the operator to select criteria for Criticality -- anything less is Non-Critical, anything more is Fatal. Other knobs may select for specific responses to different forms of Critical and Non-Critical errors. This is all starting to look complicated :-( But at least it avoids trying to square the circle. [When you have eliminated the impossible, what remains, ....] At a practical level, I observe: 1) if (or as) most implementations only send one collection of NLRI per message, then extracting one collection is enough to be reasonably sure there are no "lost NLRI". 2) the worst case of "lost NLRI" is lost Withdrawn NLRI... which, per (1), are going to be the only NLRI in the message, and hence unlikely to be lost. So, a knob or two can allow the operator to settle on what works best for them, and allow the implementer to provide stuff which an adult operator may use in the privacy of their own network. And, one can envisage Emergency Knobs -- for when there is limited time to Save the World, and being fastidious about the specification just gets in the way. Stepping back from the minutiae of unpacking UPDATE messages, in routeing terms the above categories are (I think): * Non-Critical: - some routes which the sender has offered have been filtered out, because the attributes were garbled, (ie treat-as-withdraw), - some routes which the sender offered had partly invalid attributes, but they have been accepted, in some form (ie other mechanisms), - BUT the routes which remain are *valid*, - AND the receiver knows which prefixes have been affected. * Critical: - some routes which the sender has offered are not available to the receiver, - some routes which should have been withdrawn may still be in use, - some routes whose attributes should have been changed may still be in use, - AND the receiver does not know which of the routes which remain are in doubt. * Fatal -- FUBAR Incidentally, in the absence of any better, novel mechanism: having reset and restarted a session, there is (much) less reason to worry about "lost NLRI" -- at least until End-of-RIB rolls up (or some time-out). But in any case, some things which are Fatal in normal running could be downgraded, for some period, after a session-reset ? Happy New Year, Chris From gdawra@cisco.com Tue Jan 1 22:13:19 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293E521F9115 for ; Tue, 1 Jan 2013 22:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSqTQsfBC33v for ; Tue, 1 Jan 2013 22:13:18 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 58FCB21F9113 for ; Tue, 1 Jan 2013 22:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=451; q=dns/txt; s=iport; t=1357107198; x=1358316798; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=JEpbnc+oiDvNBeivgGlvBGMy5Bp++3vAjoJwYQS6S8U=; b=N3e/9hbH7nu3wrb16MhodLKt4Q4Zk65tirddYLigfkCml1E9/y/y3+ZA 4EUOttDaziuga7Y3p8s8OnEEdv7VONhW/DkW740N/VvH+LHuPsLVv5LPR ykdzRSsgyTXlFEvVKgLQepBY+xxgekL4dyV3p2mWCMC4hz+RGweIdQ6Su A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEXAA3P41CtJV2d/2dsb2JhbABFgX+DdLdnFnOCIAEEAQEBNzQdAQgOFBQ3CyUCBAESCIgLDLdrBJA5YQOmVIJ0giY X-IronPort-AV: E=Sophos;i="4.84,394,1355097600"; d="scan'208";a="157965573" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 02 Jan 2013 06:13:18 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r026DHw6003449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 06:13:17 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 00:13:17 -0600 From: "Gaurav Dawra (gdawra)" To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 Thread-Index: AQHN6LBBdlgt/Ish00KhrzwpE9i4jw== Date: Wed, 2 Jan 2013 06:13:16 +0000 Message-ID: In-Reply-To: <1E7FEC1C-9D27-4B66-9431-D0954708E94C@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.125.43] Content-Type: text/plain; charset="us-ascii" Content-ID: <89B7E32624DD42469E0D1F3D5C5CD699@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] WG adoption requested for draft-svshah-interdomain-sla-exchange-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 06:13:19 -0000 Support. Thanks, -Gaurav On 12/6/12 2:39 PM, "John Scudder" wrote: >Folks, > >The authors have requested IDR adopt >draft-svshah-interdomain-sla-exchange-03 as a working group document. > >Please send any comments to the list by the Winter Solstice (December 21). > >Thanks, > >--John >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From rjs@rob.sh Wed Jan 2 03:39:01 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58221F909B; Wed, 2 Jan 2013 03:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vctg7HnjL0Ni; Wed, 2 Jan 2013 03:39:01 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id DF08421F9099; Wed, 2 Jan 2013 03:39:00 -0800 (PST) Received: from [217.41.228.29] (helo=[10.10.2.216]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1TqMbq-0003QA-09; Wed, 02 Jan 2013 11:35:46 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Rob Shakir In-Reply-To: <03c501cde845$54f82b30$fee88190$@highwayman.com> Date: Wed, 2 Jan 2013 11:39:07 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0A1782EC-9389-4F95-A7DC-BD9B67686EB7@rob.sh> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> To: Chris Hall , Jeff Wheeler X-Mailer: Apple Mail (2.1499) Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 11:39:01 -0000 On 1 Jan 2013, at 17:27, Chris Hall wrote: > [=85snip=85] Hi All. I think this is a good summary of the different approaches. In = ops-reqs-for-bgp-error-handling-06, there is no category of "fatal" = essentially because (as you highlight) the line between the fatal and = the critical cases is somewhat blurry. I would propose that we do not = add another category of error for "fatal". If I go back to the proposal I made on 31/12: > Would the GROW working group be happy if we address Chris' concern = related to "lost NLRI" (which AFAICS is really the case where we have >1 = type of NLRI attribute within a single message) by adding a note that an = error remains Non-Critical if _at least one_ NLRI attributes can be = successfully parsed? I'm unclear here as to whether we're addressing a = common situation where multiple sets of NLRI are being contained within = a single message [1]. If so, then adding "at least one" and then a = further point that an implementation SHOULD use a single NLRI attribute = per UPDATE message, and put this at the start of the attributes would = seem to be a fair way forward. I would suggest that adding the following wording to =A7 3 of the draft = addresses this, and clarifies the issue of "lost" NLRI: "An error SHOULD be defined as Non-Critical if at least one NLRI = attribute within an erroneous message can be successfully parsed. In = cases where more than one attribute containing NLRI is included within a = single UPDATE message, this may result in cases where some NLRI = contained within subsequent attributes are missed, particularly where = length errors exist in the message. In order to minimise the risk of = such occurrences, it is recommended that an implementation SHOULD = include only one attribute containing NLRI per message."=20 Additionally -- from the discussions that Jeff Wheeler raised, around = repeated errors. In =A7 5, it seems that there is a further requirement, = which I would suggest that we state as: "In order to address repeated instances of critical errors, an = implementation SHOULD provide a means by which an operator can enable = such errors to be ignored. Where a mechanism of this nature is = implemented, it provides a means by which an operator may avoid = prolonged session failure which results in isolation from one, or more, = routing domains. An operator deploying such a mechanism MUST be aware = that holding such sessions up may result in inconsistency within the = RIB, which may cause incorrect forwarding of traffic (e.g., loops, or = blackholing)." Some feedback on whether this addresses the points discussed over the = last few days would be appreciated. Happy New Year, r.= From jared@puck.nether.net Wed Jan 2 07:26:38 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF61321F8525; Wed, 2 Jan 2013 07:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNzG53wp3gMw; Wed, 2 Jan 2013 07:26:38 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDC321F8505; Wed, 2 Jan 2013 07:26:38 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id r02FQXgO008570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Jan 2013 10:26:34 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <03c501cde845$54f82b30$fee88190$@highwayman.com> Date: Wed, 2 Jan 2013 10:26:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> To: "Chris Hall" X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 02 Jan 2013 10:26:34 -0500 (EST) Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 15:26:38 -0000 On Jan 1, 2013, at 12:27 PM, Chris Hall wrote: > It is a truth universally acknowledged (AFAICS), that if NLRI in a > broken UPDATE are treated-as-withdraw, that is no worse than > session-reset and much to be preferred. >=20 > So, treat-as-withdraw is a reasonable thing for any implementation to > do, by default, where it can. >=20 > The problem is that when things are broken, it may not be possible to > identify all the NLRI -- some may be "lost". [At this point I > recommend: "The Engineer", AA Milne.] I've been following this draft and wanted to chime in with some = concerns. 1) in the (big) "Internet" space, lost NLRI are a huge deal for = customers. 2) When we see a software defect that results in a session being closed, = we regularly need help from the vendor to identify the offending = NLRI/message. 3) The biggest problems we've seen are where vendor A and vendor B (or = their sub-variants that run another OS) behave differently with the same = NLRI. I've seen a small number of theses cases over the past ~12 years and am = very concerned with the amount of effort trying to error correct the = error handling system when one side has a software defect. I want to = make it clear that all these cases attempting to resync at 0xffff etc = are correcting for a defect. Some of these defects resulted in an = improperly formatted UPDATE message from a sender, and others were the = result of problems on the receiver. The instability this possibly introduces into an enterprise or large = scale network is of significant concern. To solve the "treat as withdraw" (aka: possibly create a per-node = routing loop) problem, I would expect BGP users to demand a "periodic = resend all NLRIs" feature to flush the state, creating further entropy = in the system unnecessarily. At some point, the equipment that is sending or receiving the BGP = message will need to be maintained by the owner. The dropping of the = session is meant to draw attention to the problem in the same way as = others that use ABORT or ASSERT in their code to handle an unexpected = condition. We can not correct for every error, nor should we make that a goal as = the results in writing the error handling code quickly get complex. = (Speaking as someone who attempted to write a BGP implementation once.. = ugh). Asbestos suit on, - Jared= From tony.li@tony.li Wed Jan 2 09:58:48 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB3B21F8786 for ; Wed, 2 Jan 2013 09:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.284 X-Spam-Level: X-Spam-Status: No, score=-100.284 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hc+U25GTlSnO for ; Wed, 2 Jan 2013 09:58:47 -0800 (PST) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:40]) by ietfa.amsl.com (Postfix) with ESMTP id 3555521F8775 for ; Wed, 2 Jan 2013 09:58:46 -0800 (PST) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta04.emeryville.ca.mail.comcast.net with comcast id j5p21k0021HpZEsA45ym4o; Wed, 02 Jan 2013 17:58:46 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta14.emeryville.ca.mail.comcast.net with comcast id j5wW1k00f52qHCY8a5wZKk; Wed, 02 Jan 2013 17:56:44 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> Date: Wed, 2 Jan 2013 09:56:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357149526; bh=EkU9Aq57tmHbIe+yDlK7UDVvGTUXTIIoFHPYZ7sA6y0=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=j50aARzRg7qMR4brAhE/O6SrWg1ppm2n92ooonwC9SdhTTAOaaS/W56R21cC/dMXY 9DZH7Nlwr6CM7h8P1tdYjYZSndOshCI4as6r6XRhhitkpbul8zRgb1dDsRrxfjcAec 0wMf5syAmUKjPd0s/j58G2JI+OO7881asmLZ73bJ/5X2LbByIAcuWvZHR/9O6hjX1X 2fCfrzH2724tE01JItxjJJ2+RXX3CQVtsEpM31hJvOY5SbReqdwov2k/7yCtc62Hc6 CitCz/kxenN1fvswogfd9ZyvQXODpAocfKPa59xRdgtB7u0wHnnnHmqakHpk3rYZoW uuaYAUkjYlkPg== Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 17:58:48 -0000 On Jan 2, 2013, at 7:26 AM, Jared Mauch wrote: > We can not correct for every error, nor should we make that a goal as = the results in writing the error handling code quickly get complex.=20 +1 I'd also like the folks in the operational community who feel that = treat-as-withdraw is a too liberal policy to please speak up. I know = folks still call their vendors and raise the roof when a single prefix = is improperly handled. Your voices need to be heard here too. While we can do SOME things to decrease session resets, we cannot fix = all cases and simply treating things as a withdraw and walking away is = wholly unacceptable, as some of you will hopefully agree. Creating = arbitrary hair here is NOT going to help as the error handling code = itself will become fraught with errors. Ergo: KISS Tony From chris.hall@highwayman.com Wed Jan 2 10:15:41 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD70721F86E7; Wed, 2 Jan 2013 10:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CChUJJCGWpLY; Wed, 2 Jan 2013 10:15:39 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta004.mxout.tbr.inty.net [91.221.168.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC2D21F8461; Wed, 2 Jan 2013 10:15:39 -0800 (PST) Received: from mdfmta004.tbr.inty.net (unknown [127.0.0.1]) by mdfmta004.tbr.inty.net (Postfix) with ESMTP id F2EAAA0C084; Wed, 2 Jan 2013 18:15:37 +0000 (GMT) Received: from mdfmta004.tbr.inty.net (unknown [127.0.0.1]) by mdfmta004.tbr.inty.net (Postfix) with ESMTP id CC2EDA0C081; Wed, 2 Jan 2013 18:15:37 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta004.tbr.inty.net (Postfix) with ESMTP; Wed, 2 Jan 2013 18:15:37 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TqSqm-000113-Rm; Wed, 02 Jan 2013 18:15:36 +0000 From: "Chris Hall" To: , References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <0A1782EC-9389-4F95-A7DC-BD9B67686EB7@rob.sh> In-Reply-To: <0A1782EC-9389-4F95-A7DC-BD9B67686EB7@rob.sh> Date: Wed, 2 Jan 2013 18:15:31 -0000 Organization: Highwayman Message-ID: <044401cde915$29b64ad0$7d22e070$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJc3CmccD8qr+UA8XZaw8qzk1ZbRwFwQA1TlwyHO6A= Content-Language: en-gb X-MDF-HostID: 9 Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 18:15:41 -0000 Rob Shakir wrote (on Wed 02-Jan-2013 at 11:39 +0000): > On 1 Jan 2013, at 17:27, Chris Hall wrote: > > [=85snip=85] =20 > I think this is a good summary of the different approaches. In ops- > reqs-for-bgp-error-handling-06, there is no category of "fatal" > essentially because (as you highlight) the line between the fatal > and the critical cases is somewhat blurry. I would propose that we > do not add another category of error for "fatal". OK. Old-fashioned session-reset (unadorned by Graceful Restart or other mitigation, past present or future) is Bad. The Fatal category would capture cases where an old-fashioned session-reset is the only available response. As old-fashioned session-reset fades into distant memory, that distinction will be less useful. I think that what this boils down to is: Non-Critical =3D> per-Message response is sufficient Critical =3D> per-Session (or possibly per-AFI/SAFI) response is required. The anatomy of per-Message response may include: 1) treat-as-withdraw all NLRI that can be identified 2) scrubbing round some attribute errors and proceeding with some or all announced NLRI. 3) other (novel) means to recover the state of particular NLRI. 4) (implicitly) ignoring any known or unknown "lost-NLRI". The anatomy of per-Session response may include: a) old-fashioned session-reset, where nothing else is available. b) complete session-drop, where patience is exhausted. c) other means, old and new, to restore the session, to some level of health. d) some means to control cycles of repeated errors generating the same (inadequate) response. [Definition of madness: doing the same thing over and over again in the expectation of a different outcome.]=20 It seems to me that there are two contexts for error-handling: (i) in normal running, and (ii) during error-recovery. Things which are deemed Critical in normal running may be deemed Non-Critical during error-recovery. That may be part of the automatic per-Session response to an error, or may be some override settable by the Operator. What an operator deems Non-Critical in normal running will depend on their assessment of the risk/impact of "lost NLRI" and the impact/cost of the available per-Session response(s). The risk of "lost NLRI" depends on sender behaviour and on the acceptable "degree-of-broken-ness". The impact of "lost NLRI" is context dependent. The impact/cost of any per-Session response depends on what is supported by both ends of the session. My conclusion is that there is no "one size fits all" allocation of errors to class of error. Hence, the requirement is for operator control over error classification and over error response/recovery -- on a per Session basis -- both for normal running and error-recovery. Having got this far... I'm tempted to back away from talking about Critical/Non-Critical *Errors*, and talk, instead, about Message-Level/Session-Level *Recovery*... not much of the existing draft would be affected if the focus shifted from Errors to Recovery. ..... > I would suggest that adding the following wording to =A7 3 of the > draft addresses this, and clarifies the issue of "lost" NLRI: >=20 > "An error SHOULD be defined as Non-Critical if at least one NLRI > attribute within an erroneous message can be successfully parsed. In > cases where more than one attribute containing NLRI is included > within a single UPDATE message, this may result in cases where some > NLRI contained within subsequent attributes are missed, particularly > where length errors exist in the message. In order to minimise the > risk of such occurrences, it is recommended that an implementation > SHOULD include only one attribute containing NLRI per message." The way in which attributes and NLRI are packed in a (current) UPDATE message is unhelpful. But, I don't think this is the place to solve that problem. Further, changes to the specification of UPDATE messages cannot ensure that software will follow that (or any other) specification. After all, we are only here because software is less than perfect ! And, there is some desire to cope with errors which cannot be addressed by any amount of specification-tweaking. And, there is the need to do better without changes at the sender end. Hence, IMHO the question of what should be handled at the Message-Level, and what should be handled at the Session-Level, is best decided by the operator... as above. Further, this approach would allow the requirements to avoid the quicksand which is UPDATE message parsing. [Huzzah !] ----- The requirements could recommend new defaults for the classification of errors. There's no absolute need for this: given the ability to choose something which suits them better, I'm sure operators will happily enable what they want. I guess any *default* would err on the side of caution, ie: Message-Level Recovery is appropriate only where there is a (vanishingly) small risk of "lost NLRI". The appropriate default for a given session may depend on the behaviour of the peer, which may be the subject of negotiation, configuration or sweeping generalisation. The requirements could recommend that UPDATE messages should be altered to reduce the risk of "lost NLRI" or be generally more robust. If that is constrained by the need for new-form UPDATE messages to be downwards compatible with existing ones, the requirements should mention that. If the default classification depends on new sender behaviour, I think that implies the requirement for a C.... but I won't repeat that heresy :-) I'm skirting around the quicksand here, I don't want to get sucked down again... Chris=20 From jakob.heitz@ericsson.com Wed Jan 2 12:05:50 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D112321F867E; Wed, 2 Jan 2013 12:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uw3CKhLXdE1j; Wed, 2 Jan 2013 12:05:49 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C005921F867D; Wed, 2 Jan 2013 12:05:38 -0800 (PST) Received: from EUSAAHC008.ericsson.se ([147.117.188.96]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r02KIwqk024597; Wed, 2 Jan 2013 14:19:00 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 15:05:11 -0500 From: Jakob Heitz To: Tony Li , Jared Mauch Thread-Topic: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN6RLnMUudy3dkzUCvAnw0oYxCOZg2dB2Q Date: Wed, 2 Jan 2013 20:05:11 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A3CC@eusaamb109.ericsson.se> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> In-Reply-To: <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 20:05:51 -0000 On , Tony Li <> wrote: > simply treating things as a withdraw > and walking away is wholly unacceptable, It's worth reiterating that Robert and I (at least) have advocated for using http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 when an error is detected but no NOTIFICATION is sent. BTW, I notice that this draft has expired. --=20 Jakob Heitz. From randy@psg.com Wed Jan 2 16:03:55 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0BA21F8889; Wed, 2 Jan 2013 16:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKNwYH6815xe; Wed, 2 Jan 2013 16:03:55 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 966D721F8881; Wed, 2 Jan 2013 16:03:55 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TqYHq-0000SP-AY; Thu, 03 Jan 2013 00:03:54 +0000 Date: Thu, 03 Jan 2013 09:03:53 +0900 Message-ID: From: Randy Bush To: Jared Mauch In-Reply-To: <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 00:03:56 -0000 > 1) in the (big) "Internet" space, lost NLRI are a huge deal for > customers. indeed. > At some point, the equipment that is sending or receiving the BGP > message will need to be maintained by the owner. early. i want to hear it from my network management system before i get a call from the customer. > We can not correct for every error, nor should we make that a goal as > the results in writing the error handling code quickly get complex. as a naggumite, i call this 'do-gooder' software. when it does the right thing, no one notices and says thanks. when it does the wrong thing, the flamage gets pretty hot, and justifiably so. randy From jsw@inconcepts.biz Thu Jan 3 08:52:12 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797721F8CA7 for ; Thu, 3 Jan 2013 08:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qllVq43nsDMO for ; Thu, 3 Jan 2013 08:52:10 -0800 (PST) Received: from mail-ia0-f175.google.com (mail-ia0-f175.google.com [209.85.210.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAAF21F8CB1 for ; Thu, 3 Jan 2013 08:52:10 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id z3so12709256iad.6 for ; Thu, 03 Jan 2013 08:52:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=zefhF1br2xZP4rK74IB34Dvho8Y8Xp0rwOXaLjFObRw=; b=WioWBtxuVTcmfcNv23OLyNtLIAgrZC638zYPJqRtyCbW52JK4avgCppx/RDhR5TEYX lV/ChJ3+gSHl+Kpcd0glakA+239sYeJXMUKZTq41U39VNRGbP3eMxVcuJ5BbV2bd6yK6 jgaWkmVKGnt3mB/zIvtFRdF81rlOLN1OomMHLQO13n/toTns30Dj8DTF347Qethj5BkU 38xSpB4zJWF5B1ypnMspSMlpFtRZI16p8rHT3GKzUNJjUXiBd522oZ5Kp8ClVRW+iAA1 pmJeQ4nCAPtifhL6uY/MWQgBg10txIam6e4i9Jc+9/d0rXkKUPl8uyxBH8H0p5r5Qvfu lqHw== MIME-Version: 1.0 Received: by 10.50.104.232 with SMTP id gh8mr42291503igb.45.1357231920166; Thu, 03 Jan 2013 08:52:00 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 3 Jan 2013 08:51:59 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> Date: Thu, 3 Jan 2013 11:51:59 -0500 Message-ID: From: Jeff Wheeler To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmiOcdEqPA7/yq749x9Y7vnMLQ/STA2jittxsQ7NcxH5nluXwbV/32pgieoViV8VtkfvQcH Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:52:12 -0000 On Wed, Jan 2, 2013 at 12:56 PM, Tony Li wrote: > While we can do SOME things to decrease session resets, we cannot fix all= cases and simply treating things as a withdraw and walking away is wholly = unacceptable, as some of you will hopefully agree. Creating arbitrary hair= here is NOT going to help as the error handling code itself will become fr= aught with errors. Tony, Every operator I've asked thinks "ignore bad BGP messages," which is even more extreme than treat-as-withdraw, is a good idea. I'm not saying anyone thinks this would be a good default. These things can just be knobs used when they are appropriate or necessary. Respectfully, you are about as wrong as one could get on this issue. Of course customers don't want one prefix to be broken. Fifteen years of "CEF problem" have taught us all that these conditions are hard to troubleshoot. However, it is often preferable to have one or many prefixes broken, than have a BGP session flap endlessly due to some bug. The vendor should have some standards body coverage for giving the operator this knob, and customers are right to ask for it. Sure, you're giving us more rope. Sometimes that is what we need. Related to this, what is your plan for dealing with BGP Attribute re-ordering in the rewrite of RFC4760? Currently there is no mechanism for telling a BGP neighbor that you intend to send the MP-NLRIs before other Attributes. Doing that goes against RFC4271's recommendations. Relying on that behavior (e.g. for error-handling) is not possible unless the neighbor promises to do it. Thus far, there seems to be no intent to allocate another Capability Code for this. The MP-BGP Capabilities Optional Parameter was not designed to be extended to do other things besides announce to the neighbor what AFI/SAFIs it supports. --=20 Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From Donald.Smith@CenturyLink.com Thu Jan 3 09:31:19 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B25111E80D2; Thu, 3 Jan 2013 09:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbEKciMAPFfK; Thu, 3 Jan 2013 09:31:18 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 88C3911E809C; Thu, 3 Jan 2013 09:31:12 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r03HV6Kq026146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2013 10:31:07 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E10F91E0053; Thu, 3 Jan 2013 10:31:00 -0700 (MST) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id A5C631E0071; Thu, 3 Jan 2013 10:31:00 -0700 (MST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r03HV0Pf003479; Thu, 3 Jan 2013 11:31:00 -0600 (CST) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r03HUxL6003459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jan 2013 11:30:59 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0318.001; Thu, 3 Jan 2013 10:30:59 -0700 From: "Smith, Donald" To: "'Jeff Wheeler'" , "'Jakob Heitz'" Thread-Topic: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN54Kas8SJjgcJ/kuMjaNWVJ0hMJg33/hw Date: Thu, 3 Jan 2013 17:30:58 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A29D756@PDDCWMBXEX503.ctl.intranet> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <20121231030925.GB62942@verdi> <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'idr@ietf.org'" , "'grow@ietf.org'" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 17:31:19 -0000 "Pampers use multiple layers of protection to prevent leakage. Rommel used = defense in depth to defend European fortresses." (A.White) Donald.Smith@Cen= turyLink.com >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >Jeff Wheeler >Sent: Monday, December 31, 2012 11:14 AM >To: Jakob Heitz >Cc: idr@ietf.org; grow@ietf.org >Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- >error-handling-06.txt > >On Mon, Dec 31, 2012 at 12:54 PM, Jakob Heitz >wrote: >> I don't think treat-as-withdraw is trying to fix a single session >reset. Graceful restart can fix that. It's the rolling resets that need >a human to remove a buggy router or a config that triggered the bug. >That takes several hours. Treat-as-withdraw limits the damage during >those hours. >> >> Could we please settle on that without trying to solve the impossible? > >If you read my posts to IDR on this topic, you'll see where I explain >how it is possible to solve the "impossible." > >Specifically, you can ignore just about any bad update, or bad message >of any kind, as long as you can figure out where the next message >starts. This fixes the rolling resets. Exactly. Ignore (not treat as withdraw, not reset session, ...) seems the s= anest approach to me also! > >You may know that a lot of businesses suffered multi-hour outages in >October simply because of 5 DFZ routes announced by LANL that had >illegal attributes. This is very hard for operators to troubleshoot >on most routers. The routers that experienced rolling resets were >buggy but if the operators simply had a panic button, "ignore bad >messages," their networks would have been up and they would not have >been losing money by the minute. > >This is not the only time bad updates have propagated through the DFZ >and caused big problems. It has happened repeatedly. > >I believe it will begin to happen more often inside datacenter >networks, because BGP is being used for more and more things, like >EVPN. Operators are going to need BGP to become more robust. > >You can make it a lot more robust just by deciding to ignore >everything in a bad message. This is not good, but it is a lot better >than session-reset, in most cases. > >Please, read my posts on this topic, and do not treat this problem as >an unsolvable one. It can be largely solved in a way that gives a >very useful fallback option to operators. > >This whole draft is about fallback options, and it is pretty stupid to >have a large amount of complexity to solve a small set of potential >bugs, when you could ALTERNATIVELY or IN ADDITION to that, have a very >low-complexity option that solves more problems. > >-- >Jeff S Wheeler >Sr Network Operator / Innovative Network Concepts >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From jared@puck.nether.net Thu Jan 3 09:40:20 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1721F86DC; Thu, 3 Jan 2013 09:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcz-ukpTXrkU; Thu, 3 Jan 2013 09:40:19 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 73A6121F86D6; Thu, 3 Jan 2013 09:40:19 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id r03HeFfd001462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jan 2013 12:40:16 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Thu, 3 Jan 2013 12:40:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <806CF05A-6EBE-47FF-A6AA-F262A288DB3D@puck.nether.net> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> To: Jeff Wheeler X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 03 Jan 2013 12:40:17 -0500 (EST) Cc: idr@ietf.org, grow@ietf.org, Tony Li Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 17:40:20 -0000 Jeff, On Jan 3, 2013, at 11:51 AM, Jeff Wheeler wrote: > On Wed, Jan 2, 2013 at 12:56 PM, Tony Li wrote: >> While we can do SOME things to decrease session resets, we cannot fix = all cases and simply treating things as a withdraw and walking away is = wholly unacceptable, as some of you will hopefully agree. Creating = arbitrary hair here is NOT going to help as the error handling code = itself will become fraught with errors. >=20 > Tony, >=20 > Every operator I've asked thinks "ignore bad BGP messages," which is > even more extreme than treat-as-withdraw, is a good idea. Not sure who you're asking, but I think this whole draft is an idealist = attempt to workaround software defects that may be uncorrectable as a = whole. (I say this as a $large_operator as measured here: = http://as-rank.caida.org/?mode0=3Das-ranking&n=3D10&ranksort=3D1 ) The missing prefix because it was ignored, or routing loop because a = withdraw was ignored will quickly change these folks minds. Take one of the most recent defects: http://www.cisco.com/en/US/products/csa/cisco-sa-20100827-bgp.html The device takes a valid route on the receive side and corrupts it as it = forwards it. While ignoring may be one solutions, there is no way to = actually know or get remediation of this prefix and software defect. There are 3 classes of BGP operators: 1) Core networks 2) Edge/Mid-tier networks 3) People using it as their IGP/datacenter/vpn/private networks (these = may eventually connect to the internet, but those UPDATE messages won't = necessarily reach) > I'm not saying anyone thinks this would be a good default. These > things can just be knobs used when they are appropriate or necessary. >=20 Methinks you underestimate the complexity that would be added to the = error handling code. While finding a marker/0xff may be easier, = understanding the large block of updates in the flood of activity and = low latency of large tcp windows make this much harder and more prone to = error. > Respectfully, you are about as wrong as one could get on this issue. > Of course customers don't want one prefix to be broken. Fifteen years > of "CEF problem" have taught us all that these conditions are hard to > troubleshoot. However, it is often preferable to have one or many > prefixes broken, than have a BGP session flap endlessly due to some > bug. For some operators, the only chance to workaround defects is to have = something catastrophic happen to provide the justification to management = to actually pick up the $new_software that corrects the problems you've = been applying band-aids to.=20 There are many people who now are having trouble diagnosing network = problems due to a workaround from early 2009: http://puck.nether.net/pipermail/cisco-nsp/2009-February/058512.html > The vendor should have some standards body coverage for giving the > operator this knob, and customers are right to ask for it. Sure, > you're giving us more rope. Sometimes that is what we need. I'm generally in the more-rope camp, but this is effectively throwing = out years of well worn code path and introducing new code (and likely = defects) in the handling of error cases which can only make things = worse. There wasn't a broad-reaching bgp attribute problem in 2012 that = i'm aware of, putting us in the "there is stability in the core" camp. = I'm seeing a well intentioned but unneeded element of meddling here. People on the edge also need to learn to maintain their devices. This = isn't a standards body issue, and IMHO off-topic for here, but an = important datapoint. - Jared From tony.li@tony.li Thu Jan 3 10:02:13 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C390F21F8C1E for ; Thu, 3 Jan 2013 10:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.611 X-Spam-Level: X-Spam-Status: No, score=-97.611 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfZZvN5jbfnn for ; Thu, 3 Jan 2013 10:02:13 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4021F8BD7 for ; Thu, 3 Jan 2013 10:02:13 -0800 (PST) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta01.emeryville.ca.mail.comcast.net with comcast id jSrR1k00A16AWCUA1W2DXP; Thu, 03 Jan 2013 18:02:13 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta06.emeryville.ca.mail.comcast.net with comcast id jW001k00K52qHCY8SW02Bq; Thu, 03 Jan 2013 18:00:11 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Thu, 3 Jan 2013 10:00:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357236133; bh=y3WiVCV+pLSwvUOw3h1cPoCrlJXUT9kIRmuTLWPjf44=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=Uyt7pnY/wiktcdU2hhGssw2dIeMS3uik+Da3rl/liK+24jBwaaYbl3CNZGfrtUghI OknnqZTFvWbwp1r2HX+b8pi98FCuSwhY227B/RKfcErePawAby1Z/O0L2Rd8ORJ2pd szklVT7UPFZDc9eD9Lk1k7yp/A4X6g6Tm5IABXGQ3uD5NnveuQHsSkTNBh+ZoPrANK FkC5sZrIraPVeRXBcmXfGFvZBukWwBZt/hL0geWZFscDVo86lpZemoykvCs9aITvZI Ha930MvaMkzVWTtjH3LMD6bo1QLHlDouUvgst0cUiB59Wn2oYJDhxvAlydxwvWPkmj U2lQ5oI94ugiQ== Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 18:02:13 -0000 Jeff, >> While we can do SOME things to decrease session resets, we cannot fix = all cases and simply treating things as a withdraw and walking away is = wholly unacceptable, as some of you will hopefully agree. Creating = arbitrary hair here is NOT going to help as the error handling code = itself will become fraught with errors. >=20 > Every operator I've asked thinks "ignore bad BGP messages," which is > even more extreme than treat-as-withdraw, is a good idea. I'm sure if you asked folks if they wanted anything that helped them and = completely ignored the costs, they would say yes. However, if you want = to make a reasonable, rational, and justified decision, you must = consider the implications of the request. That's what I'm asking. = Consider implementor input as well, because there are some practical = considerations here. > Respectfully, you are about as wrong as one could get on this issue. Respectfully, I think you're misunderstanding my position completely. = My point is that a reasonable implementation cannot possibly live up to = the expectations that you're setting up here. To be specific, once an = implementation loses the syntactic parsing of the data stream, = realistically, the session is corrupt and an eventual reset is = inevitable. Or, in other words, BGP cannot possible ignore bad = messages. That's not the way it works. > Of course customers don't want one prefix to be broken. Fifteen years > of "CEF problem" have taught us all that these conditions are hard to > troubleshoot. However, it is often preferable to have one or many > prefixes broken, than have a BGP session flap endlessly due to some > bug. All of the marketing that you're doing here is positioning this as a = 'solution'. It's not. Yes, it will stop the flap, but it does NOTHING = to fix or deal with the underlying bug. All it does is gloss it over, = and as such, it will have implications in the field whereby this papers = over real bugs and we have now promoted BGP errors into RIB errors. = That's NOT making things easier to debug, that's just applying a = band-aid. A more constructive way to address the real problem here would be to = talk about whether we should even re-establish the session after an = error. Long ago, we made an implementation decision to simply retry. = That would seem to be the real issue at hand. > The vendor should have some standards body coverage for giving the > operator this knob, and customers are right to ask for it. Sure, > you're giving us more rope. Sometimes that is what we need. Sorry, but the point of the standards body is to standardize PROTOCOL = changes. Everything that has been discussed here are IMPLEMENTATION = ISSUES. We don't standardize those, for very good reasons. And the = vendors need zero help from the IETF in making implementation issues. = If real customers want a particular behavior, they can always just ask = for it, as always. > Related to this, what is your plan for dealing with BGP Attribute > re-ordering in the rewrite of RFC4760? =20 My plan? My personal plan is to ban the use of all MP extensions, as = all of that is simply evil and should be scrubbed off the face of the = earth. =20 I'll be putting this in place as soon as I'm elected Emperor of the = Universe. ;-) > Currently there is no > mechanism for telling a BGP neighbor that you intend to send the > MP-NLRIs before other Attributes. Doing that goes against RFC4271's > recommendations. Relying on that behavior (e.g. for error-handling) > is not possible unless the neighbor promises to do it. Thus far, > there seems to be no intent to allocate another Capability Code for > this. The MP-BGP Capabilities Optional Parameter was not designed to > be extended to do other things besides announce to the neighbor what > AFI/SAFIs it supports. RFC 4271 doesn't require a specific ordering because it would be bad = protocol design. As soon as you require ordering, some implementation = is going to check that ordering. There will be more bugs that occur = because the mandated ordering was not followed, and more sessions will = be dropped. As always, the right thing is to follow Postel's law: be = liberal in what you accept. =20 Requiring a specific ordering in order to improve error handling is a = bad tradeoff: you're creating a host of additional bugs so that you can = try to simplify error handling on another set of bugs. Tony From rraszuk@gmail.com Thu Jan 3 10:50:13 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB1021F869B; Thu, 3 Jan 2013 10:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwLXTi8ZJ62X; Thu, 3 Jan 2013 10:50:12 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC6721F8692; Thu, 3 Jan 2013 10:50:12 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id k10so19107738iea.29 for ; Thu, 03 Jan 2013 10:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ymgXddIZoNjrvsJBjE2MrnDKVnflbHMUP43cuklaT9M=; b=Mgqj/7ITIfUM7o4OvILBgZdINNajcg2lFAskXlBERDSFARHpq21Ly6X/nm8OabgqFf lNaNY4nxeObiEfAAb7rdYOYDoTkcgE2Nf93jOrt9gMvHQ39pUJbHFHb2rmbwLP9jGEjN 5+8zVsmU7oWiuz2wpIjcoHkN9bhciGrqViE4nTgenWbVqXD47fewraRz4Er67O4xrc4T orPj5e4hJbPEsRqV81ocjrI8APg5HaeQVPS7KqdzybAVX8h6MxtVko/+/LomGQH1SytM q7Kb9sYUGpzfXM76pS5jyd3Mz6qFQIZzvhed0/ad73whxHK3PJTn2VRpYJ7/1vxMiI22 aYGA== MIME-Version: 1.0 Received: by 10.50.41.231 with SMTP id i7mr38648632igl.98.1357239008851; Thu, 03 Jan 2013 10:50:08 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.167.204 with HTTP; Thu, 3 Jan 2013 10:50:08 -0800 (PST) In-Reply-To: <68EFACB32CF4464298EA2779B058889D0A29D756@PDDCWMBXEX503.ctl.intranet> References: <025801cde4f6$d7783700$8668a500$@highwayman.com> <3B3C1AA7-40DB-4566-9BD0-C25E5845935D@rob.sh> <028701cde525$bf262070$3d726150$@highwayman.com> <20121231030925.GB62942@verdi> <6D642BD9-C87F-4987-9C32-0A4463E6A542@ericsson.com> <68EFACB32CF4464298EA2779B058889D0A29D756@PDDCWMBXEX503.ctl.intranet> Date: Thu, 3 Jan 2013 19:50:08 +0100 X-Google-Sender-Auth: YjteBN7nie4602ezDuGNnSjJiko Message-ID: From: Robert Raszuk To: "Smith, Donald" Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 18:50:13 -0000 > On Thu, Jan 3, 2013 at 6:30 PM, Smith, Donald wrote: > Exactly. Ignore (not treat as withdraw, not reset session, ...) seems the sanest approach to me also! That's equally good as starting to drill little holes in the ship in the middle of ocean. Sure it will still swim for a while, but when it starts to drown it will be too late. You may as well run BGP over UDP and have app level acks for received datagrams. Problem solved - no sessions resets to worry about. Cheers, R. From jsw@inconcepts.biz Thu Jan 3 11:22:51 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4940A21F8CF9 for ; Thu, 3 Jan 2013 11:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eei5e05iPUVi for ; Thu, 3 Jan 2013 11:22:50 -0800 (PST) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7641721F86F4 for ; Thu, 3 Jan 2013 11:22:48 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id s32so12845599iak.40 for ; Thu, 03 Jan 2013 11:22:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=QQNWR3dviH/iq9/nJFuf3gjIcsTnacBHyt08pPi429g=; b=F9hHO6Hxk4ohDAtrE4cptGv2vq1YxmeuU7CLjCskv+emYdiHpLoAr/laG/qtSxTd/f SUd3iuo/vdcpVmuNkW/7cgiNqtt+MtMkoWUbfhLcugB8FPec2iPGiLk/txjZGn6CSIvZ G/fBricZWt45vTFns+Esix4KVIC0v/A0q/5/UgAeXxg/o0MsLw9ERMkMikKAsvk9khbl lyWXqJ4qJjMwxdXX5sPLQ12L7gmivtC10HyeBNNdbahzMDB19vAgTUZuUd7WwnQzkMaO WAB4enEL84cLtn9WhbhccUEbyy/y6VPbiFqh2irotmlE5RKFsLrzGjtvJ+dQ1NBLG5R0 e1JQ== MIME-Version: 1.0 Received: by 10.50.152.240 with SMTP id vb16mr42253550igb.45.1357240967982; Thu, 03 Jan 2013 11:22:47 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 3 Jan 2013 11:22:47 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <806CF05A-6EBE-47FF-A6AA-F262A288DB3D@puck.nether.net> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <806CF05A-6EBE-47FF-A6AA-F262A288DB3D@puck.nether.net> Date: Thu, 3 Jan 2013 14:22:47 -0500 Message-ID: From: Jeff Wheeler To: Jared Mauch , Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlKyuJd0mNXVy7WroM/HGVAnGerIETBVQu+Cx9fDkFpBv2FgtjFj8lywFoI0sEh+Jnfi9pR Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:22:52 -0000 On Thu, Jan 3, 2013 at 12:40 PM, Jared Mauch wrote: > Not sure who you're asking, but I think this whole draft is an idealist a= ttempt to workaround software defects that may be uncorrectable as a whole.= (I say this as a $large_operator as measured here: http://as-rank.caida.o= rg/?mode0=3Das-ranking&n=3D10&ranksort=3D1 ) > > The missing prefix because it was ignored, or routing loop because a with= draw was ignored will quickly change these folks minds. Yes, the existing draft contains a great deal of complexity to work around specific problems that have been imagined. It would be very simple to just ignore bad updates. That is not complicated. It's not "good" but it's less bad than your network being down because you received one bad update from your DFZ neighbor, which in the case of a small network, might be one or all of their transit providers. Having had to support networks who were down because of this condition recently, I understand their pain, because they were down with no hope of being back up until external parties helped them. > Methinks you underestimate the complexity that would be added to the erro= r handling code. While finding a marker/0xff may be easier, understanding = the large block of updates in the flood of activity and low latency of larg= e tcp windows make this much harder and more prone to error. I don't think I underestimate it at all. I think the complexity introduced by the error-handling draft is a bad idea. I know that "ignore bad updates" is extremely simple and a very broad catch-all tool which can be utilized if there are no better options. Having your network be down because you can't keep BGP sessions to your transit providers established is not an option. > For some operators, the only chance to workaround defects is to have some= thing catastrophic happen to provide the justification to management to act= ually pick up the $new_software that corrects the problems you've been appl= ying band-aids to. Your position is that you don't want a feature that can mitigate problems, because it would provide you with an opportunity to mitigate problems instead of fix them? Do you have to sabotage your network to get problems fixed or capacity upgraded, too? > I'm generally in the more-rope camp, but this is effectively throwing out= years of well worn code path and introducing new code (and likely defects)= in the handling of error cases which can only make things worse. There wa= sn't a broad-reaching bgp attribute problem in 2012 that i'm aware of, putt= ing us in the "there is stability in the core" camp. I'm seeing a well int= entioned but unneeded element of meddling here. LANL's announcement of invalid paths caused about 3000 prefixes to instantly disappear from the DFZ. This lasted for several hours. Those missing prefixes are just networks who didn't have any working transit at all. Some small networks that I worked with were affected on only some transit sessions and not others. The affect of this is difficult to measure, but almost 1% of the DFZ disappearing because of one bad update demonstrates just why BGP is a very vulnerable single point-of-failure. > People on the edge also need to learn to maintain their devices. This is= n't a standards body issue, and IMHO off-topic for here, but an important d= atapoint. While true, if their vendor hasn't identified and corrected a bug yet, they don't have any software upgrade option. I believe this was recently the case for Alcatel during same event caused by the LANL announcements. On Thu, Jan 3, 2013 at 1:00 PM, Tony Li wrote: > I'm sure if you asked folks if they wanted anything that helped them and = completely ignored the costs, they would say yes. However, if you want to = make a reasonable, rational, and justified decision, you must consider the = implications of the request. That's what I'm asking. Consider implementor= input as well, because there are some practical considerations here. Do you think the error-handling draft is too complex to be worth implementing? I do. That is exactly why I suggest "ignore bad messages" as an alternative. It is not complicated. > Respectfully, I think you're misunderstanding my position completely. My= point is that a reasonable implementation cannot possibly live up to the e= xpectations that you're setting up here. To be specific, once an implement= ation loses the syntactic parsing of the data stream, realistically, the se= ssion is corrupt and an eventual reset is inevitable. Or, in other words, = BGP cannot possible ignore bad messages. That's not the way it works. Of course BGP can ignore bad messages. To say otherwise is simply telling a lie because you haven't made a good argument. There are three types of situations worth considering. 1) message is bad and we don't know if Message Length is, because another MARKER hasn't yet arrived This is very easy to deal with. Simply ignore the message. If a MARKER doesn't arrive next, reset the session. Avoids complexity. Your code should already be able to deal with a message that contains nothing it understands -- for example, a message with no NLRI and nothing but an optional, non-transitive attribute that it doesn't recognize. 1) message is bad but Message Length is fine, and the next MARKER appears as expected This is also very easy to deal with. Just ignore the message. It is exactly the same as the above case except perhaps you waited for the next message to start arriving before you decided what to do about the previous, corrupt message. 2) message is bad and Message Length is bad, so the next MARKER is not where it should be This is a little harder to deal with. It may be a lot harder for a BGP implementation that pathologically integrates TCP and BGP Message parsing. Perhaps some implementations would choose to try to recover without session-reset by hoping a new MARKER will arrive soon to "re-sync" the session. Perhaps not. I think the value of this is quite questionable and highly dependent on how much work it is for the implementor -- and what he feels are the chances of introducing new bugs. > All of the marketing that you're doing here is positioning this as a 'sol= ution'. It's not. Yes, it will stop the flap, but it does NOTHING to fix = or deal with the underlying bug. All it does is gloss it over, and as such= , it will have implications in the field whereby this papers over real bugs= and we have now promoted BGP errors into RIB errors. That's NOT making th= ings easier to debug, that's just applying a band-aid. It does do something to keep the network functioning. Is it functioning well? No, of course not. But there may be only 1 or a few routes that are bad. In the case of the LANL incident, 5 /24s were bad. I can live with not being able to reach 5 /24s that were announced with bad attribute flags. I can even live with a loop in my network for those /24s. I can't live with my network down because BGP is flapping. You are right, this is a band-aid. It is a very good one when you are bleeding money. > A more constructive way to address the real problem here would be to talk= about whether we should even re-establish the session after an error. Lon= g ago, we made an implementation decision to simply retry. That would seem= to be the real issue at hand. If you have received bad messages from all your transit providers, it will not matter if you re-establish the sessions or not, if the bad messages keep coming. All your transit will be down and you'll be bleeding money. > Sorry, but the point of the standards body is to standardize PROTOCOL cha= nges. Everything that has been discussed here are IMPLEMENTATION ISSUES. = We don't standardize those, for very good reasons. And the vendors need ze= ro help from the IETF in making implementation issues. If real customers w= ant a particular behavior, they can always just ask for it, as always. Would you like a list of some standards-track documents that do not modify protocols? >> Related to this, what is your plan for dealing with BGP Attribute >> re-ordering in the rewrite of RFC4760? > > My plan? My personal plan is to ban the use of all MP extensions, as all= of that is simply evil and should be scrubbed off the face of the earth. > > I'll be putting this in place as soon as I'm elected Emperor of the Unive= rse. ;-) I agree that MP-BGP is less than ideal. That's true of many extensions to BGP. Sadly, there isn't BGP-5, and BGP-5 would be needed to clean all of this up. The reason I ask is because the work on MP-BGP makes a specific recommendation to re-order the attributes in such a way that is the opposite of a specific recommendation in the base BGP spec. If other work, such as error-handling, wants to depend on the MP-BGP recommendation being followed, then MP-BGP should actually provide a way for the neighbor to signal its intent to follow that recommendation. That can and perhaps should be done with a new Capability Code. If that is not done, then a lot of the rules in the error-handling draft are not useful unless error-handling itself allocates such Capability Code. I don't understand the reason for adding this recommendation to MP-BGP if you don't also think there should be a mechanism by which you and your neighbor can agree to depend on it. Also, I'd like to repeat that a lot of the rules in error-handling are not useful unless the neighbor supports it. This means it might be useful within your datacenter network but is probably not useful to most transit or peers for a long time. > RFC 4271 doesn't require a specific ordering because it would be bad prot= ocol design. As soon as you require ordering, some implementation is going= to check that ordering. There will be more bugs that occur because the ma= ndated ordering was not followed, and more sessions will be dropped. As a= lways, the right thing is to follow Postel's law: be liberal in what you ac= cept. > > Requiring a specific ordering in order to improve error handling is a bad= tradeoff: you're creating a host of additional bugs so that you can try to= simplify error handling on another set of bugs. I gather that your general opinion is error-handling is bad. In addition, you think that specifically promising to order attributes in the way needed by error-handling is further bad. Do you think the recommendation for ordering attributes should be removed from RFC4760bis? IMO this is important. --=20 Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From mlong@us.ntt.net Thu Jan 3 11:35:56 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BAA21F8D00; Thu, 3 Jan 2013 11:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRJXgSD+MOB7; Thu, 3 Jan 2013 11:35:55 -0800 (PST) Received: from destroyer.troyspaws.com (destroyer.troyspaws.com [IPv6:2001:418:c01::27]) by ietfa.amsl.com (Postfix) with ESMTP id A765321F8CFF; Thu, 3 Jan 2013 11:35:55 -0800 (PST) Received: from [192.168.1.108] (99-16-97-27.lightspeed.snrsca.sbcglobal.net [99.16.97.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by destroyer.troyspaws.com (Postfix) with ESMTP id B49515C207E5; Thu, 3 Jan 2013 19:35:54 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Long In-Reply-To: Date: Thu, 3 Jan 2013 11:35:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> To: Tony Li X-Mailer: Apple Mail (2.1499) Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:35:56 -0000 On Jan 3, 2013, at 10:00 AM, Tony Li wrote: >=20 >=20 > All of the marketing that you're doing here is positioning this as a = 'solution'. It's not. Yes, it will stop the flap, but it does NOTHING = to fix or deal with the underlying bug. All it does is gloss it over, = and as such, it will have implications in the field whereby this papers = over real bugs and we have now promoted BGP errors into RIB errors. = That's NOT making things easier to debug, that's just applying a = band-aid. I understand what you are saying and I agree 100%, however, from an my = operations perspective the "fix" is the same. Either upgrade to fixed = code or policy out the offending announcement. I would rather deal with = a customer routing issue vs a frantic call from our noc saying 15+ att = peers globally are bouncing. The latter being a much bigger impact on = our network.=20 I can live with a couple of /24's not working for a few customers. I = can't have 15+ peers bouncing because of bad updates and even more peers = bouncing because of missed keepalives due to cpu pegged trying to deal = with 15 peers bouncing globally.=20 >=20 > A more constructive way to address the real problem here would be to = talk about whether we should even re-establish the session after an = error. Long ago, we made an implementation decision to simply retry. = That would seem to be the real issue at hand. I would back this provided adequate logging as to why the session is = down. It would be much like tripping max-prefixes where we could hard = clear a single single session for debug. I could live with this.=20 Mike --=20 Michael Long NTT Communications Global IP Network ph. 214.915.1352 jabber: mlong@jabber.gin.ntt.net From enkechen@cisco.com Thu Jan 3 11:36:11 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA6C21F8D2C; Thu, 3 Jan 2013 11:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.371 X-Spam-Level: X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WYfkjA70Y4L; Thu, 3 Jan 2013 11:36:10 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 209A421F8CFF; Thu, 3 Jan 2013 11:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3448; q=dns/txt; s=iport; t=1357241769; x=1358451369; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=tmfAlhV/UsZ2PAH0VdMoXbPYKjzL83DzcRz7urYMtjg=; b=c97EXntFX7X5AKqxfMzPhh0aVdhLA5UkgVpFrM1Rv0xuNxquGxt0+q3S 3n8DwgkvwTlvq8kf+GpOGRx5VBGu2z9MWEcqkBUiYLt72aY+5Mahm4etl lCLthmhEgNV0JeOQcselQu5xtlwMylOC5VZsHvPiVFVZYYswFh+nF+3E1 k=; X-IronPort-AV: E=Sophos;i="4.84,404,1355097600"; d="scan'208,217";a="22767278" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 03 Jan 2013 19:36:07 +0000 Received: from [171.71.139.31] (dhcp-171-71-139-31.cisco.com [171.71.139.31]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r03Ja40n021644; Thu, 3 Jan 2013 19:36:05 GMT Message-ID: <50E5DDA3.5060709@cisco.com> Date: Thu, 03 Jan 2013 11:36:03 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jeff Wheeler References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <806CF05A-6EBE-47FF-A6AA-F262A288DB3D@puck.nether.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030105080406040904070108" Cc: idr@ietf.org, grow@ietf.org, Tony Li Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:36:11 -0000 This is a multi-part message in MIME format. --------------030105080406040904070108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hi, Jeff: On 1/3/13 11:22 AM, Jeff Wheeler wrote: [snip] > >> Respectfully, I think you're misunderstanding my position completely. My point is that a reasonable implementation cannot possibly live up to the expectations that you're setting up here. To be specific, once an implementation loses the syntactic parsing of the data stream, realistically, the session is corrupt and an eventual reset is inevitable. Or, in other words, BGP cannot possible ignore bad messages. That's not the way it works. > Of course BGP can ignore bad messages. To say otherwise is simply > telling a lie because you haven't made a good argument. > > A good argument (IMO) has been made in the error handling draft: --------- http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ 4. Operational Considerations Note that "treat-as-withdraw" is different from discarding an UPDATE message. The latter violates the basic BGP principle of incremental update, and could cause invalid routes to be kept. (See also Appendix A.) --------- -- Enke --------------030105080406040904070108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
hi, Jeff:

On 1/3/13 11:22 AM, Jeff Wheeler wrote:

[snip]


Respectfully, I think you're misunderstanding my position completely.  My point is that a reasonable implementation cannot possibly live up to the expectations that you're setting up here.  To be specific, once an implementation loses the syntactic parsing of the data stream, realistically, the session is corrupt and an eventual reset is inevitable.  Or, in other words, BGP cannot possible ignore bad messages.  That's not the way it works.

Of course BGP can ignore bad messages.  To say otherwise is simply
telling a lie because you haven't made a good argument.

A good argument (IMO) has been made in the error handling draft:

---------
http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/

4. Operational Considerations
   Note that "treat-as-withdraw" is different from discarding an UPDATE
   message.  The latter violates the basic BGP principle of incremental
   update, and could cause invalid routes to be kept.  (See also
   Appendix A.)
---------

-- Enke

--------------030105080406040904070108-- From jared@puck.nether.net Thu Jan 3 11:58:07 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E75621F85ED; Thu, 3 Jan 2013 11:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eNXp7CLDyNy; Thu, 3 Jan 2013 11:58:06 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4711921F85E8; Thu, 3 Jan 2013 11:58:06 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id r03Jw2WX026264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jan 2013 14:58:03 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Thu, 3 Jan 2013 14:58:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> To: Michael Long X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 03 Jan 2013 14:58:04 -0500 (EST) Cc: idr@ietf.org, grow@ietf.org, Tony Li Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:58:07 -0000 On Jan 3, 2013, at 2:35 PM, Michael Long wrote: >=20 > On Jan 3, 2013, at 10:00 AM, Tony Li wrote: >>=20 >>=20 >> All of the marketing that you're doing here is positioning this as a = 'solution'. It's not. Yes, it will stop the flap, but it does NOTHING = to fix or deal with the underlying bug. All it does is gloss it over, = and as such, it will have implications in the field whereby this papers = over real bugs and we have now promoted BGP errors into RIB errors. = That's NOT making things easier to debug, that's just applying a = band-aid. >=20 > I understand what you are saying and I agree 100%, however, from an my = operations perspective the "fix" is the same. Either upgrade to fixed = code or policy out the offending announcement. I would rather deal with = a customer routing issue vs a frantic call from our noc saying 15+ att = peers globally are bouncing. The latter being a much bigger impact on = our network.=20 I'm very concerned with the case of ignoring a route update and having a = month-long discussion about why some route is missing from the = $carrier_a network when it's being sent from $carrier_b and they show it = going out just fine. You don't know there's an issue until someone reports it and your = long-tail to problem resolution takes forever. > I can live with a couple of /24's not working for a few customers. I = can't have 15+ peers bouncing because of bad updates and even more peers = bouncing because of missed keepalives due to cpu pegged trying to deal = with 15 peers bouncing globally.=20 While related, this is an implementation defect on the part of vendors = and their poorly optimized TCP and BGP implementations being unable to = get their basic job done. I recall vendors blaming our "slow" system = CPU then finally fixing their logic defect that always returned 1 or 0 = when it thought it was idle. (sometimes those if statements look really = complex). >> A more constructive way to address the real problem here would be to = talk about whether we should even re-establish the session after an = error. Long ago, we made an implementation decision to simply retry. = That would seem to be the real issue at hand. >=20 > I would back this provided adequate logging as to why the session is = down. It would be much like tripping max-prefixes where we could hard = clear a single single session for debug. I could live with this.=20 I certainly agree there needs to be better logging from the vendors. I remain convinced that attempts to address this problem will create = more complex situations vs provide the desired result of a stable BGP = core. - Jared= From jsw@inconcepts.biz Thu Jan 3 12:05:46 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0247621F8DC6 for ; Thu, 3 Jan 2013 12:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6ooGTcWYwwe for ; Thu, 3 Jan 2013 12:05:45 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6002C21F8DBF for ; Thu, 3 Jan 2013 12:05:45 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so18946566ieb.3 for ; Thu, 03 Jan 2013 12:05:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KoTy5Hoynb1b4pOvfTehiHIN3K+bOGTz7bcR78DAqRk=; b=Nb8Hx2TwlFYTQwZ79AqVfCryh4fwLRh32eXpSFR4XSbcCgG5an6e6KVstTDfW/u+6u IOBkV76Z/KLqx79rt5sGJiKs4bwthZMxGHKbu1ZM9FeiaFJ/irRUE/T8bfgFCOQhsdUG DyNV5c4eW/J7yHXkYJTJ9C1ruf6i5RmVFkRWwRArAxlYcu8TpREmxdQIh+K2OLDN4jKB ZmNZHDQ+YBe3QW7WOD6LP/PWueLu66idUgOkfAFO7m5qJbguyjDVMtaO7Gk72uC1ZDC7 APYY3ppaByo8faG+OUcG1sELi4l2jO8hhPWnN42+nFFDWRn/M+HPzsJxPpYCOT68j+9/ KxCw== MIME-Version: 1.0 Received: by 10.50.104.232 with SMTP id gh8mr42715935igb.45.1357243544985; Thu, 03 Jan 2013 12:05:44 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 3 Jan 2013 12:05:44 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> Date: Thu, 3 Jan 2013 15:05:44 -0500 Message-ID: From: Jeff Wheeler To: Michael Long , enkechen@cisco.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl76v6C+mIqyu9bzZGodshuPhvVsK8HQ7cSb8Vr6vqKn6+Q1EKRsar8fV6uMD3iMQOOb4R+ Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 20:05:46 -0000 On Thu, Jan 3, 2013 at 2:35 PM, Michael Long wrote: > Either upgrade to fixed code or policy out the offending announcement. You actually can't policy out the announcement on the receiving side. This is why I continue to state that you need help from external parties to solve these problems. Vendor, BGP neighbor, etc. When I got called because some of my transit customers were having their sessions flap endlessly and their routers were logging errors they did not understand, it took be about an hour to figure out what prefixes were causing it. That's because my router had equally poor logging. Then I asked the customers if they wanted me to filter out the 5 bad prefixes from going to them. That is what they needed until they could upgrade their software. On Thu, Jan 3, 2013 at 2:36 PM, Enke Chen wrote: > A good argument (IMO) has been made in the error handling draft: > > --------- > http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ > > 4. Operational Considerations > > Note that "treat-as-withdraw" is different from discarding an UPDATE > message. The latter violates the basic BGP principle of incremental > update, and could cause invalid routes to be kept. (See also > Appendix A.) I hope we all understand that treat-as-withdraw violates exactly the same principle. It just throws away routes which may be valid, instead of keeping them. I don't understand the perspective from which you are looking at this problem. From mine, there could be a buggy router in my AS, and it could be withdrawing routes from its RIB. Then other routers could be trying to transit traffic across that router, which is then mis-routed (could be looped) or discarded. The error-handling draft does not keep the RIB in a good state. Anyone who thinks otherwise is simply incorrect. So treat-as-withdraw puts the RIB in a bad state. Ignore-bad-message puts the RIB in a bad state. Exactly how it is bad differs, but treat-as-withdraw in the current draft is very complicated and does not provide a band-aid for "all" problems. Ignore-bad-message is very simple and provides a band-aid for more problems, including unforeseen problems. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From rraszuk@gmail.com Thu Jan 3 12:18:17 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BDB21F8CD7; Thu, 3 Jan 2013 12:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfNanO1TUf-S; Thu, 3 Jan 2013 12:18:17 -0800 (PST) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id B686C21F86AA; Thu, 3 Jan 2013 12:18:10 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id x2so13202059iad.13 for ; Thu, 03 Jan 2013 12:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MbNSvARGedGHiab26we4mCykbiJitAMaucTvgM4brHU=; b=KR62OOCr7dI6sD+p+RkfUBuCBTHSYac3wjakS/LDLhJ8n02rP1JIxZyP6LTBfv1ACb xF24rCpg6wvi9hMM+DMBRZ20piS04TEOBzWKrdBiqA1HUbXnedkzV7wzWAq5hdK9e9p/ E43+ZVib4TwNWVYeu3k5QBkBm6gqpDrps9rx0QVTEY9r9Wb+4mjNR8dGGS87MRcH81iT tyX3+bTdyMT7l75DzTMGGYsWW1dkzQjHiAF+RM5I2bDsYiZNZVfzu9tSj0I7HD6KGscR 9Gk39vPvkY4iyIFT7v0lIDAuDeWZVAeLAWoX8I/KFeZdMh8xQ+IP/aira9FSXkU3nRys MwHQ== MIME-Version: 1.0 Received: by 10.50.41.231 with SMTP id i7mr38835124igl.98.1357244290134; Thu, 03 Jan 2013 12:18:10 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.167.204 with HTTP; Thu, 3 Jan 2013 12:18:09 -0800 (PST) In-Reply-To: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> Date: Thu, 3 Jan 2013 21:18:09 +0100 X-Google-Sender-Auth: 4OwqZ3nXQyPDJbfOjCmu3zpLDrU Message-ID: From: Robert Raszuk To: Jeff Wheeler Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 20:18:17 -0000 Hi Jeff, > Ignore-bad-message is very simple and provides a band-aid for more > problems, including unforeseen problems. How are you going to clean the NLRIs in your network (both transit or stub) which were withdrawn in the messages your BGP implementation declared "bad" and decided to ignore ? r. From internet-drafts@ietf.org Thu Jan 3 12:56:30 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58DC21F8D26; Thu, 3 Jan 2013 12:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.193 X-Spam-Level: X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sNIr5SWIoPB; Thu, 3 Jan 2013 12:56:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CB121F867D; Thu, 3 Jan 2013 12:56:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130103205630.3871.46704.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2013 12:56:30 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 20:56:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Inter-domain SLA Exchange Author(s) : Shitanshu Shah Keyur Patel Sandeep Bajaj Luis Tomotaki Mohamed Boucadair Filename : draft-ietf-idr-sla-exchange-00.txt Pages : 23 Date : 2013-01-03 Abstract: Network administrators typically provision QoS policies for their application traffic (such as voice, video) based on SLAs negotiated with their providers, and translate those SLAs to 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 operational transitive attribute to signal SLA details in-band, across administrative boundaries (considered as Autonomous Systems (AS)), and thus simplify/speed-up some of the complex tasks. Though the use-case with the proposed 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From chris.hall@highwayman.com Thu Jan 3 13:11:23 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C512721F8D63; Thu, 3 Jan 2013 13:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-2u1Lapce8U; Thu, 3 Jan 2013 13:11:23 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta005.mxout.tbr.inty.net [91.221.168.46]) by ietfa.amsl.com (Postfix) with ESMTP id C445921F8D61; Thu, 3 Jan 2013 13:11:22 -0800 (PST) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id CE82FA642FC; Thu, 3 Jan 2013 21:11:20 +0000 (GMT) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id AA3C5A642F5; Thu, 3 Jan 2013 21:11:20 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tbr.inty.net (Postfix) with ESMTP; Thu, 3 Jan 2013 21:11:20 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Tqs4N-00012D-Jg; Thu, 03 Jan 2013 21:11:19 +0000 From: "Chris Hall" To: , Date: Thu, 3 Jan 2013 21:11:14 -0000 Organization: Highwayman Message-ID: <051101cde9f6$e051b450$a0f51cf0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3p9tqXZ6AxQf7wTw69zzvTCQm03Q== Content-Language: en-gb X-MDF-HostID: 8 Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 21:11:23 -0000 Jared Mauch wrote (on Thu 03-Jan-2013 at 17:40 +0000): .... > Not sure who you're asking, but I think this whole draft is an > idealist attempt to workaround software defects that may be > uncorrectable as a whole. (I say this as a $large_operator as > measured here: http://as-rank.caida.org/?mode0=as- > ranking&n=10&ranksort=1 ) > > The missing prefix because it was ignored, or routing loop because a > withdraw was ignored will quickly change these folks minds. I agree with you: if a software defect breaks routeing, then no amount of extra software can put it together again. I also agree with you: the issue of "lost NLRI" has to be addressed. I do not know whether some routeing issues are *always* worse than wholesale loss of routeing, or wholesale bouncing up and down of routes. But some folk would like to be given the choice. I think that some extra facilities to mitigate the effects of software defects can be devised, and each operator can then decide which ones are appropriate to the circumstances, from time to time. > Take one of the most recent defects: > > http://www.cisco.com/en/US/products/csa/cisco-sa-20100827-bgp.html > > The device takes a valid route on the receive side and corrupts it > as it forwards it. While ignoring may be one solutions, there is no > way to actually know or get remediation of this prefix and software > defect. That is an interesting case. I understand that the bug was: Attribute Type 99 was received with a length of 3000 bytes; that attribute was sent out as if it was 184 bytes, except that the Length Field in the outgoing attribute still said 3000. This is a fine example of a broken attribute hiding any and all attributes which follow it. Note that the Message Length, Withdraw Length and Total Attributes Length were consistent with each other and with what was actually sent -- so the overall UPDATE Message was "correctly framed". What appears to have happened here is that some previously unused and under-tested code for handling unknown, optional, transitive attributes did something foolish. 3000 is 0xBB8 and 184 is 0xB8. So, the left hand knew that the attribute length was two bytes, while the right hand only used the less significant byte. If the programmer had got things consistently wrong, and used the less significant byte of the length throughout, there would have been far less excitement ! One can draw some comfort from the fact that the packing of the overall message -- code which is exercised micro-second in, micro-second out -- got things right. A very small minority of routes carried the Attribute 99. So, crashing the session threw away many entirely innocent routes. And, of course, the bug didn't go away, so sessions cycled up and down. In this particular case the source of Attribute 99 shut itself down within 30 minutes -- because that was the planned duration for the experiment, *not* because it had been identified as the source of some calamity. So, perhaps unusually, the source of the problem simply went away. I wonder if future latent bugs will be swept up as quickly ? Suppose such a latent bug strikes a particularly common BGP implementation. Suppose I am a little ISP and both my Transit Providers' border routers do something equally unfortunate. And suppose either: a) sessions bounce up and down until... until... or: b) my shiny new BGP implementation recovers from this Message-Level error by treating-as-withdraw the affected prefix(es)... ...vote now :-) Chris From jsw@inconcepts.biz Thu Jan 3 13:19:59 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5733C21F8BCE for ; Thu, 3 Jan 2013 13:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qhym2aOmvrFm for ; Thu, 3 Jan 2013 13:19:58 -0800 (PST) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) by ietfa.amsl.com (Postfix) with ESMTP id 716CE21F8B6D for ; Thu, 3 Jan 2013 13:19:58 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id s32so13043056iak.26 for ; Thu, 03 Jan 2013 13:19:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=VB1oEF5eTAd+ovvAxVi609AsHGoQJTr8iiQDMpyvHVc=; b=BpHFn5P/Bq81VQwUYVLMxirxdXN3zfaOP2olg4H/eEIhQ2KKxUt+n3svVOJMpRl4es TP0kmmBssMVH7DQBoKchCzkELO7HbYkoeqUR6GQqUAm4PuZFhGPMYC9404WltJptyD24 MFdjTA9y8Yr1uILIRdmMMjlbi6KhFBpOAueJmeewRGrK6rtTZmr8OOxLMBGL4psj4EQV ypcOPJrJYaTZRZvp6fB7ZnNwfYCp223o21Q1JxWcaoa6OCxRrpGCnNy7IiOxuLPQQKVy 9Mx2h4n3zJa48gfhb3sSrxNt4CLaAZ1sZP4TrTnQCZyNp0ZlszJ5zzjntsRJxeGs0Zyp 6hkw== MIME-Version: 1.0 Received: by 10.50.187.225 with SMTP id fv1mr39120986igc.96.1357247997718; Thu, 03 Jan 2013 13:19:57 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 3 Jan 2013 13:19:57 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> Date: Thu, 3 Jan 2013 16:19:57 -0500 Message-ID: From: Jeff Wheeler To: Robert Raszuk Content-Type: multipart/alternative; boundary=14dae9340fe1c6b13104d268eca0 X-Gm-Message-State: ALoCoQlSOTZBW03l+jZhLjp9lKfdlBsOiaP6ZugNZHWfypyah5OhfeEuKvgmhcHaQvAKoBLqqVzQ Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 21:19:59 -0000 --14dae9340fe1c6b13104d268eca0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 3, 2013 at 3:18 PM, Robert Raszuk wrote: > How are you going to clean the NLRIs in your network (both transit or > stub) which were withdrawn in the messages your BGP implementation > declared "bad" and decided to ignore ? I can fix them later, maybe even after I've had time to fully analyze the problem and get a software update from my vendor. Maybe I'll try a refresh or a session-reset, but I won't be at the mercy of repeatedly flapping session and phone ringing off the hook with angry customers! A lot of folks are thinking about this problem in the context of the big carrier who doesn't want a hard-to-diagnose problem of 1 RIB entry being wrong. That's okay, it is one way to think about it. A second way to think of it is as a small/regional ISP. If one or more of his transits are flapping because of a bad path on the DFZ, that is going to cost him money and customers. If he has no way to mitigate it, he is at the mercy of external parties. He could just use "ignore bad messages" and at least stop bleeding money. He does not care if he can't reach 5 /24s at LANL, they are unimportant to him. What is important is if he has any customers left next week. A third way is the small- or medium-datacenter network. Imagine you are a typical small/medium shop and you have some Cisco/Juniper/Brocade stuff for your ASBRs and your core, but you bought a bunch of RainbowPoop Router Co switches for your racks, because they are inexpensive and they support EVPN, L3VPN, VPLS, or some other feature you want but Cisco/Juniper/Brocade don't put into their inexpensive product. So your network looks like this: ISP1 ISP2 CISCO JUNIPER | \/ | /\ \ | | / \ \ | TOR1 TOR2 .... TOR99 Now imagine your JUNIPER supports NewVpnThing and that's a feature you decided to use on the RainbowPoop TOR devices. But TOR1 sends a bad BGP update. JUNIPER knows about NewVpnThing and sees a bad BGP attribute (that it recognizes) so it does whatever the NewVpnThing spec says, and tears down the session to TOR1. CISCO on the other hand, does not know about NewVpnThing so this router doesn't even understand the update is bad. It just passes it along to TOR2 .. TOR99. Now those boxes all tear down their session to the CISCO. Then they re-establish. Then they go down again. They keep on doing this and the network is freaking out. By the time your in-house clue notices, your symptom is that 99 identical TORs are flapping their BGP to your CISCO. You probably don't even notice the 1 TOR that is flapping to JUNIPER. Maybe JUNIPER even logs something helpful but you may not investigate it for a while. So your CISCO which is following the base spec is carrying a buggy update to your 99 other RainbowPoop TORs and they are all failing. Your JUNIPER which knows about the NewVpnThing is following its spec and protecting the other TORs from this problem, but it is probably not helpful since your network is in chaos from all the flapping. What do you do? Call vendor support. Probably for CISCO and RainbowPoop. Well, now you are expecting the TAC of Cisco and the TAC of RainbowPoop to cooperate, which they'll have trouble doing; and it may take ages before anyone identifies the root cause of the problem is really TOR1. There are going to be a lot of RainbowPoop routers in the future, and many of them may use BGP. We should make BGP more robust. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts --14dae9340fe1c6b13104d268eca0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 3, 2013 at 3:18 PM, Robert Raszuk <robert@raszuk.net> wrote:
> How are you going to c= lean the NLRIs in your network (both transit or
> stub) which were wi= thdrawn in the messages your BGP implementation
> declared "bad" and decided to ignore ?

I can fix them= later, maybe even after I've had time to fully analyze the problem and= get a software update from my vendor. =A0Maybe I'll try a refresh or a= session-reset, but I won't be at the mercy of repeatedly flapping sess= ion and phone ringing off the hook with angry customers!

A lot of folks are thinking about this problem in the context of the bi= g carrier who doesn't want a hard-to-diagnose problem of 1 RIB entry be= ing wrong. =A0That's okay, it is one way to think about it.

A second way to think of it is as a small/regional ISP. =A0If one or m= ore of his transits are flapping because of a bad path on the DFZ, that is = going to cost him money and customers. =A0If he has no way to mitigate it, = he is at the mercy of external parties. =A0He could just use "ignore b= ad messages" and at least stop bleeding money. =A0He does not care if = he can't reach =A05 /24s at LANL, they are unimportant to him. =A0What = is important is if he has any customers left next week.

A third way is the small- or medium-datacenter network. =A0Imagine you = are a typical small/medium shop and you have some Cisco/Juniper/Brocade stu= ff for your ASBRs and your core, but you bought a bunch of RainbowPoop Rout= er Co switches for your racks, because they are inexpensive and they suppor= t EVPN, L3VPN, VPLS, or some other feature you want but Cisco/Juniper/Broca= de don't put into their inexpensive product.

So your network looks like this:

ISP1 =A0 =A0ISP2
=A0 CISCO =A0JUNIPER
=A0 | =A0 =A0\/
=A0 | =A0 =A0/\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0 |
=A0 | =A0 / =A0\ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ =A0|
jsw= @inconcepts.biz>
Sr Network Operator =A0/ =A0Innovative Network Concepts
--14dae9340fe1c6b13104d268eca0-- From jared@puck.nether.net Thu Jan 3 13:28:05 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3874621F86C3; Thu, 3 Jan 2013 13:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmQIy8dE6AyR; Thu, 3 Jan 2013 13:28:04 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9028B21F865B; Thu, 3 Jan 2013 13:28:04 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id r03LS1Qv007713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jan 2013 16:28:02 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: Date: Thu, 3 Jan 2013 16:28:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> To: Jeff Wheeler X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 03 Jan 2013 16:28:02 -0500 (EST) Cc: idr@ietf.org, grow@ietf.org, Robert Raszuk Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 21:28:05 -0000 On Jan 3, 2013, at 4:19 PM, Jeff Wheeler wrote: > On Thu, Jan 3, 2013 at 3:18 PM, Robert Raszuk = wrote: > > How are you going to clean the NLRIs in your network (both transit = or > > stub) which were withdrawn in the messages your BGP implementation > > declared "bad" and decided to ignore ? >=20 > I can fix them later, maybe even after I've had time to fully analyze = the problem and get a software update from my vendor. Maybe I'll try a = refresh or a session-reset, but I won't be at the mercy of repeatedly = flapping session and phone ringing off the hook with angry customers! They're going to complain no matter what. Also, if you're not a fully-peered DFZ ISP, perhaps you don't need full = routes to make your decisions anyways. I am sympathetic to a point, but either way someone has to look at the = problem and correct it (likely with a code spin) assuming you don't take = the offending device offline. This is the shared fate everyone has in the BGP world for the = distributed online database we operate. Also, if you're seeing some problem, I'm sure that some other set of = people out there will be seeing it as well. The shared pain/cost will = exist. If you can't take the risk of speaking BGP, have your ISP send = you default (or nothing) and advert your prefixes and call it a day. - jared= From rraszuk@gmail.com Thu Jan 3 13:28:44 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20121F86C3; Thu, 3 Jan 2013 13:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADWpExsvSxHa; Thu, 3 Jan 2013 13:28:43 -0800 (PST) Received: from mail-ia0-f173.google.com (mail-ia0-f173.google.com [209.85.210.173]) by ietfa.amsl.com (Postfix) with ESMTP id 21B8321F865B; Thu, 3 Jan 2013 13:28:43 -0800 (PST) Received: by mail-ia0-f173.google.com with SMTP id w21so13254803iac.18 for ; Thu, 03 Jan 2013 13:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=epRXKGXvCn3gccj9mn/2neVz9496J5B6ZPbsnBWlnw0=; b=AgmllRDzbP7+UPlqzqwDa0tpU3qVEaQvXNmDRnFufYEoxK/urMmu2Mdiz3DCPJjLec KmZ6k1aUu7rl+7oCJeObWLtnp4YYBOwAvB0GCH7sdtfu2H5TdhASdbYrFacEflm0xsno CpsTy7CltXnKF7TAIqBFAr4r2SrNzT33f9fJT6fzP/BYcpoXXxujxm08xq56MuRr8z4Z EEzFJRWqITBxMTSCYxASaZdOIZB42p0asTyVIWyc3srG6Lxc4InoC4sVdajxj8Njn+/2 O8fWvLRfWDXJeiwiVc/IUMFwPXV0itfvsceWyCpdZUGpmt5nu3WN1oVJbllDiFeNhL+Q NEvg== MIME-Version: 1.0 Received: by 10.50.94.134 with SMTP id dc6mr38291492igb.80.1357248522216; Thu, 03 Jan 2013 13:28:42 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.167.204 with HTTP; Thu, 3 Jan 2013 13:28:42 -0800 (PST) In-Reply-To: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> Date: Thu, 3 Jan 2013 22:28:42 +0100 X-Google-Sender-Auth: zu81QcNrGPlweIRUKrEKnyiZUqg Message-ID: From: Robert Raszuk To: Jeff Wheeler Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 21:28:44 -0000 Jeff, > I can fix them later, maybe even after I've had time to fully analyze the > problem and get a software update from my vendor. Well that assumes you have even noticed the problem in the first place. On the point of flapping - completely agree. But the knob - already available in some implementations - not to flap, but to keep the session down till manual intervention - is completely different thing and this is completely safe solution from protocol correctness pov. -- Yes I understand your motivations, but the problem with BGP doing things like treat-as-withdraw by default are really not what you are describing. Cheers, R. On Thu, Jan 3, 2013 at 10:19 PM, Jeff Wheeler wrote: > On Thu, Jan 3, 2013 at 3:18 PM, Robert Raszuk wrote: >> How are you going to clean the NLRIs in your network (both transit or >> stub) which were withdrawn in the messages your BGP implementation >> declared "bad" and decided to ignore ? > > I can fix them later, maybe even after I've had time to fully analyze the > problem and get a software update from my vendor. Maybe I'll try a refresh > or a session-reset, but I won't be at the mercy of repeatedly flapping > session and phone ringing off the hook with angry customers! > > A lot of folks are thinking about this problem in the context of the big > carrier who doesn't want a hard-to-diagnose problem of 1 RIB entry being > wrong. That's okay, it is one way to think about it. > > A second way to think of it is as a small/regional ISP. If one or more of > his transits are flapping because of a bad path on the DFZ, that is going to > cost him money and customers. If he has no way to mitigate it, he is at the > mercy of external parties. He could just use "ignore bad messages" and at > least stop bleeding money. He does not care if he can't reach 5 /24s at > LANL, they are unimportant to him. What is important is if he has any > customers left next week. > > A third way is the small- or medium-datacenter network. Imagine you are a > typical small/medium shop and you have some Cisco/Juniper/Brocade stuff for > your ASBRs and your core, but you bought a bunch of RainbowPoop Router Co > switches for your racks, because they are inexpensive and they support EVPN, > L3VPN, VPLS, or some other feature you want but Cisco/Juniper/Brocade don't > put into their inexpensive product. > > So your network looks like this: > > ISP1 ISP2 > > CISCO JUNIPER > | \/ > | /\ \ | > | / \ \ | > TOR1 TOR2 .... TOR99 > > Now imagine your JUNIPER supports NewVpnThing and that's a feature you > decided to use on the RainbowPoop TOR devices. But TOR1 sends a bad BGP > update. JUNIPER knows about NewVpnThing and sees a bad BGP attribute (that > it recognizes) so it does whatever the NewVpnThing spec says, and tears down > the session to TOR1. > > CISCO on the other hand, does not know about NewVpnThing so this router > doesn't even understand the update is bad. It just passes it along to TOR2 > .. TOR99. Now those boxes all tear down their session to the CISCO. Then > they re-establish. Then they go down again. They keep on doing this and > the network is freaking out. > > By the time your in-house clue notices, your symptom is that 99 identical > TORs are flapping their BGP to your CISCO. You probably don't even notice > the 1 TOR that is flapping to JUNIPER. Maybe JUNIPER even logs something > helpful but you may not investigate it for a while. > > So your CISCO which is following the base spec is carrying a buggy update to > your 99 other RainbowPoop TORs and they are all failing. Your JUNIPER which > knows about the NewVpnThing is following its spec and protecting the other > TORs from this problem, but it is probably not helpful since your network is > in chaos from all the flapping. > > What do you do? Call vendor support. Probably for CISCO and RainbowPoop. > Well, now you are expecting the TAC of Cisco and the TAC of RainbowPoop to > cooperate, which they'll have trouble doing; and it may take ages before > anyone identifies the root cause of the problem is really TOR1. > > There are going to be a lot of RainbowPoop routers in the future, and many > of them may use BGP. We should make BGP more robust. > > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From chris.hall@highwayman.com Thu Jan 3 13:49:01 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD4C21F8D63; Thu, 3 Jan 2013 13:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.312 X-Spam-Level: X-Spam-Status: No, score=-0.312 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcEkYi5PWFjs; Thu, 3 Jan 2013 13:49:01 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tbr.inty.net [91.221.168.50]) by ietfa.amsl.com (Postfix) with ESMTP id D7AAA21F8D61; Thu, 3 Jan 2013 13:49:00 -0800 (PST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 5A876384083; Thu, 3 Jan 2013 21:48:59 +0000 (GMT) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id 4093E384081; Thu, 3 Jan 2013 21:48:59 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP; Thu, 3 Jan 2013 21:48:59 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Tqsen-00012I-QO; Thu, 03 Jan 2013 21:48:58 +0000 From: "Chris Hall" To: , Date: Thu, 3 Jan 2013 21:48:52 -0000 Organization: Highwayman Message-ID: <051801cde9fc$228a93f0$679fbbd0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3p/B8DLkTuV2qMRGSIZ+VdYn4fOw== Content-Language: en-gb X-MDF-HostID: 4 Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 21:49:01 -0000 Robert Raszuk wrote (on Thu 03-Jan-2013 at 20:18 +0000): > To: Jeff Wheeler > > Hi Jeff, > > > Ignore-bad-message is very simple and provides a band-aid for more > > problems, including unforeseen problems. > How are you going to clean the NLRIs in your network (both transit > or stub) which were withdrawn in the messages your BGP > implementation declared "bad" and decided to ignore ? It's a good question. But not, I think, the entire question. However bad or difficult to clean up, what if that's not as bad as the alternative ? [So: all alone somewhere up a remote, cold mountain you slip and your arm gets stuck firmly in a crevice. Clearly, you are fond of it and hacking it off has its drawbacks. But compared to hypothermia... ? Mind you, if mountaineering standards are dead-set against the hacking off of arms, perhaps your mountaineering equipment won't include a knife :-)] Chris From jsw@inconcepts.biz Thu Jan 3 14:01:10 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD91C21F8D68 for ; Thu, 3 Jan 2013 14:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7PN75kX3+LA for ; Thu, 3 Jan 2013 14:01:09 -0800 (PST) Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) by ietfa.amsl.com (Postfix) with ESMTP id 273AA21F8D7A for ; Thu, 3 Jan 2013 14:01:09 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id t4so12998697iag.39 for ; Thu, 03 Jan 2013 14:01:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=N5gbpLsm99xrON5H+PvRkpdeiMLte8Vnw4Nu7kOdxe4=; b=amSPu5OPBxe4izhbjEtCsOX2DjKfcjmAeVSoJyyr30WyA7rA12zmX7w9+HVvw4ID9I Xdzz2TearL6q3YYSkadtAkS2vYPn/XlI44Gux3zcxMOy89wUlUVbKrxMYw2CoVpxiV4L U1Yz7qwSuDhIJqViWrDPutBWmubJJ/lLSYd/q/ORPYqhsHpr87ySEG31p/YWpM293YdW naRtwChWJg5QpvEuRKGPZ8PTpyDP71ayhwjINZcjA2puldpr4jbuc/ul0ANrqoeI0tHq /Gz5rRu0phEiAlvYruAKY7ZGSLYNNv5UXKBBGcXLeBWjcf+yyQsO098LqIWBqEDZt5bt Ww/w== MIME-Version: 1.0 Received: by 10.50.187.225 with SMTP id fv1mr39200775igc.96.1357250468349; Thu, 03 Jan 2013 14:01:08 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 3 Jan 2013 14:01:08 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> Date: Thu, 3 Jan 2013 17:01:08 -0500 Message-ID: From: Jeff Wheeler To: Jared Mauch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQllETbBQSiIuKYsaO7IPdKvW4H/qyyzVr9tXH5ke/GgYpcfVA9Vk2D8z4DtpPxLL7/mimC6 Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:01:10 -0000 On Thu, Jan 3, 2013 at 4:28 PM, Jared Mauch wrote: > Also, if you're seeing some problem, I'm sure that some other set of > people out there will be seeing it as well. The shared pain/cost will > exist. If you can't take the risk of speaking BGP, have your ISP send you > default (or nothing) and advert your prefixes and call it a day. There may be no shared pain if you are using BGP only within your datacenter network. This is precisely why I provided the RainbowPoop scenario. This is not your 1990s BGP anymore. Anyone who has MPLS VPNs signaled using BGP already knows this but maybe isn't cognizant of it in this context. You continue to make this argument that breaking your network so you notice a problem is good. I would like to have the option to notice the problem by actually parsing my syslogs and NOT having my network break and cost me and customers a bunch of money. That's not what I would really do, though. I would just re-actively configure ignore-bad-messages if I needed to. Because I agree with you, I would like BGP to flap if something unexpected happens. However, I might need to stop it from flapping to remain in business. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From jared@puck.nether.net Thu Jan 3 14:05:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272D721F8D8C; Thu, 3 Jan 2013 14:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN01FY0p9dq4; Thu, 3 Jan 2013 14:05:35 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFF721F8D87; Thu, 3 Jan 2013 14:05:35 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id r03M5S5g012806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jan 2013 17:05:29 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: Date: Thu, 3 Jan 2013 17:05:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> To: Jeff Wheeler X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 03 Jan 2013 17:05:29 -0500 (EST) Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:05:36 -0000 On Jan 3, 2013, at 5:01 PM, Jeff Wheeler wrote: > On Thu, Jan 3, 2013 at 4:28 PM, Jared Mauch = wrote: >> Also, if you're seeing some problem, I'm sure that some other set of >> people out there will be seeing it as well. The shared pain/cost = will >> exist. If you can't take the risk of speaking BGP, have your ISP = send you >> default (or nothing) and advert your prefixes and call it a day. >=20 > There may be no shared pain if you are using BGP only within your > datacenter network. This is precisely why I provided the RainbowPoop > scenario. This is not your 1990s BGP anymore. Anyone who has MPLS > VPNs signaled using BGP already knows this but maybe isn't cognizant > of it in this context. >=20 > You continue to make this argument that breaking your network so you > notice a problem is good. I would like to have the option to notice > the problem by actually parsing my syslogs and NOT having my network > break and cost me and customers a bunch of money. That's not what I > would really do, though. I would just re-actively configure > ignore-bad-messages if I needed to. Because I agree with you, I would > like BGP to flap if something unexpected happens. However, I might > need to stop it from flapping to remain in business. Oh, I understand all these use-cases, but there is a case for a = well-designed network not always sharing/mixing the NLRI. eg: We don't = transport v4 NLRI in v6 transport, nor v6 NLRI in v4 transport. If you = have a single session with massive shared fate, perhaps it's not a = protocol design error but a network design error. - Jared= From tony.li@tony.li Thu Jan 3 14:07:49 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C8421F8CF8 for ; Thu, 3 Jan 2013 14:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.56 X-Spam-Level: X-Spam-Status: No, score=-99.56 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDJx0i4hh9Zn for ; Thu, 3 Jan 2013 14:07:48 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 784ED21F8CE0 for ; Thu, 3 Jan 2013 14:07:48 -0800 (PST) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta02.emeryville.ca.mail.comcast.net with comcast id jTV11k0011eYJf8A2a7oq9; Thu, 03 Jan 2013 22:07:48 +0000 Received: from [10.155.35.198] ([128.107.239.234]) by omta19.emeryville.ca.mail.comcast.net with comcast id ja5a1k00L547xYo01a5cFv; Thu, 03 Jan 2013 22:05:45 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <051801cde9fc$228a93f0$679fbbd0$@highwayman.com> Date: Thu, 3 Jan 2013 14:05:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <02C95055-0597-4574-AF2E-F6AB5C473051@tony.li> References: <051801cde9fc$228a93f0$679fbbd0$@highwayman.com> To: "Chris Hall" X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357250868; bh=7tj3GwFVwtE7RDKCQog3ZQHc3DOQyf6eTzqMSqFnD/M=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=RJ5HyW5iXXORNI0RoawiUaC1RM02ecepd0MQErtTM06r1fCqi2B5FJrdztFOwE0+e eUoum5LB58yf/i9oEdG+yyJ3rJXxy5IAW6o5G2zaoRGRj1Y+t0RgPmvqtRYkRxcRTX u9mxosxrTfRI21T2WKVZaB8ydScVyHPaqoBoyPPLyfOnwWajxb7FkFXynC+N89hlGX 1NesxcPRMNX6t++O9CEMghopSx0XRr/gf3WH5HckfrZ/u9+/wL51po/XHOmktVB8z5 Tp6k9hkNzO40kvfTExe/79Si7qsUSWS48yCsi5wpKtcz9kaWOTcRxZhWgXC3isk4iG 8JQXes2vKgAyQ== Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:07:49 -0000 On Jan 3, 2013, at 1:48 PM, "Chris Hall" = wrote: > However bad or difficult to clean up, what if that's not as bad as the > alternative ? Clearly, the treat-as-withdraw alternative is better. You're not = leaving bogus state in the rest of the network. Tony From jsw@inconcepts.biz Thu Jan 3 14:15:51 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565E421F8D77 for ; Thu, 3 Jan 2013 14:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCheBC1Izw7B for ; Thu, 3 Jan 2013 14:15:50 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6B24121F8D75 for ; Thu, 3 Jan 2013 14:15:44 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id c11so18982778ieb.33 for ; Thu, 03 Jan 2013 14:15:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=s2vl52g4iRiszy6f1UOL2fLIFIOxsgyXobP7inM8JGs=; b=nKsf9+vTDj4190qBqhEZBWCQc0va+ESVn5ZFOfHHSoWeLY9WwQIFiTknG1k15db8KW LJrOfc7+4iwDrBzMWt2ZAztjuMbHzYG2sRXImLOY4ozgN0To4a5ppJKHeJSms/E9ziiG EkpfIUlkN8tcFs4JFs+MnvvKzW0w92J/jGSwCPvev06bNDJd/sWigp29E1LPJr3fJREP A8p3tFg7bDN1e43cp4ZFaueGuT+7fzH94MWg8n58eKcP2YVkSwr4UxA+t4tapnkL4GRL UtL+VpP7nLhp2xvdWKp2c1rR1Zp28MuaDrd0U4S9NN9wLqEsTLzyObDoQLwQv2H/m7ie JLXw== MIME-Version: 1.0 Received: by 10.50.104.232 with SMTP id gh8mr42965712igb.45.1357251340401; Thu, 03 Jan 2013 14:15:40 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 3 Jan 2013 14:15:40 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> Date: Thu, 3 Jan 2013 17:15:40 -0500 Message-ID: From: Jeff Wheeler To: Jared Mauch , Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnuPtDQFyix7FYcuBYH0cwb83e9IICNya6dA7el3RMWTof8jFXkhpqX1Y3s4Wx92RHsMCxC Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:15:51 -0000 On Thu, Jan 3, 2013 at 5:05 PM, Jared Mauch wrote: > Oh, I understand all these use-cases, but there is a case for a well-desi= gned network not always sharing/mixing the NLRI. eg: We don't transport v4= NLRI in v6 transport, nor v6 NLRI in v4 transport. If you have a single s= ession with massive shared fate, perhaps it's not a protocol design error b= ut a network design error. it is not just a shared-fate problem. Even if you have distinct BGP sessions per AFI, the RainbowPoop scenario still breaks the datacenter network if they actually depend on NewVpnThing. Most networks will still have a very hard time troubleshooting it, and they'll be bleeding customers until they do. I noticed you've omitted MPLS VPNs. We also do not use the same BGP sessions for IPv4 and IPv6, but we do use IPv4 sessions for MPLS VPNs. It is avoidable but I would bet that most networks do not avoid it. Do yours? On Thu, Jan 3, 2013 at 5:05 PM, Tony Li wrote: > On Jan 3, 2013, at 1:48 PM, "Chris Hall" wrot= e: >> However bad or difficult to clean up, what if that's not as bad as the >> alternative ? > > Clearly, the treat-as-withdraw alternative is better. You're not leaving= bogus state in the rest of the network. Does this mean you support treat-as-withdraw, even though you dislike its high complexity? My read of your postings today is that you dislike the whole error-handling idea. --=20 Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From tony.li@tony.li Thu Jan 3 14:18:35 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6A421F8D8E for ; Thu, 3 Jan 2013 14:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.885 X-Spam-Level: X-Spam-Status: No, score=-99.885 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pLM47xa3+cZ for ; Thu, 3 Jan 2013 14:18:34 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 81BE421F8CFF for ; Thu, 3 Jan 2013 14:18:34 -0800 (PST) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta12.emeryville.ca.mail.comcast.net with comcast id jRkG1k0031wfjNsACaJaod; Thu, 03 Jan 2013 22:18:34 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta23.emeryville.ca.mail.comcast.net with comcast id jaGK1k00e52qHCY8jaGNNj; Thu, 03 Jan 2013 22:16:32 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Thu, 3 Jan 2013 14:16:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357251514; bh=pRCmZq2SX0RoJ70Nns1pppVpU9/pNXuASb0NnQXd/4U=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=ZU4MHTGr66G0A5bU8+Ac2i/HFkj3BbPxdX5wbh/3EgHsYBxfC1Fv6lx0RQBPN6FBN zCEJAb5LrryzlRWmkMFJBqFuAeopXc6CoQc422PSno3q/DOp9HwS7+yz9AkXLctxSy /e0FoB6aBmO2D77FZdYKnoQC7qh0d89I0dSwVz6z8tR73hGIYpBGkUBn6Qb0ACFEHy /s82xeWhbPIHYNWo3OBhY7iE7RFhMy97fN3a9krYWz89lKA1A0HkywesfvQmthNFXu X7JKcp9kfgVzfYbpu9ZYNloKgbWTU/r//KYhKmvYNih0p/BSjncT3oj/HCPInlq33U wvtqN5Ng0ZLUg== Cc: idr@ietf.org, grow@ietf.org, Robert Raszuk Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:18:35 -0000 On Jan 3, 2013, at 1:19 PM, Jeff Wheeler wrote: > A lot of folks are thinking about this problem in the context of the = big carrier who doesn't want a hard-to-diagnose problem of 1 RIB entry = being wrong. That's okay, it is one way to think about it. Unfortunately, the code is NOT going to be that sensitive to the = variations of the use case. The same code that the Tier 1 carrier is = using is the same code on much smaller systems. We need to find a = behavior that is amenable to all. > We should make BGP more robust. I'm glad we agree on one thing. Tony From jsw@inconcepts.biz Thu Jan 3 14:23:58 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FE921F8626 for ; Thu, 3 Jan 2013 14:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuCJnJjPYApu for ; Thu, 3 Jan 2013 14:23:58 -0800 (PST) Received: from mail-ia0-f169.google.com (mail-ia0-f169.google.com [209.85.210.169]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA6821F876E for ; Thu, 3 Jan 2013 14:23:57 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id u20so6700602iag.14 for ; Thu, 03 Jan 2013 14:23:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EXIk5F39lNII/LpoAL/mXwr5+LR2dAnLc9oy0oSAsaQ=; b=mP6c9BsA5rYryRB3g/NoKWzdR5iV+CK6B+5FDFKsVjkagD34cHdaTqQeBTryJXGgLa CwSq4PmI4uG4g4RwJo5MwqFb4Cis/QZpkPpFfLoHXFzayZCYxc06qQpL0mvuLBrKNMM2 7CG8OQRZFrlJiXceLD90lfNbl0GSfHHo48GpXh8GZK6iSMHOp44l0tNxaqOzZzS96uHm YDU9uz7iSFV6lkdqXFZdjxvHorS2x56YVGR7y29+o7V+c/bshWVfJameb5LUNL7uhCTP m7Cv845SvDr4P84TU1xGLlcNgwEyW916i15P0NC5gmEwG4BLs3aRljF7xpl5CNlYLaYx yUQg== MIME-Version: 1.0 Received: by 10.50.152.240 with SMTP id vb16mr42603328igb.45.1357251836882; Thu, 03 Jan 2013 14:23:56 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 3 Jan 2013 14:23:56 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> Date: Thu, 3 Jan 2013 17:23:56 -0500 Message-ID: From: Jeff Wheeler To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlQpy0ffM8dOMOiPrh/6s2JFGdoV+f289rA//504e8OZciJpvemYV07x9D1CJCoKhmMNmTO Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:23:58 -0000 On Thu, Jan 3, 2013 at 5:16 PM, Tony Li wrote: > Unfortunately, the code is NOT going to be that sensitive to the variations of the use case. The same code that the Tier 1 carrier is using is the same code on much smaller systems. We need to find a behavior that is amenable to all. One behavior may not suit all cases. That's why we have options. If we only had one router I guess it would be the biggest, most expensive router possible; because big networks need these. Fortunately vendors understand that they need to produce options to suit different kinds of customers. They also need to produce configuration knobs to suit different kinds of customers. This standards body creates options every time it uses a capitalized word except MUST or MUST NOT. If options weren't needed, RFC2119 would be a lot shorter. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From tony.li@tony.li Thu Jan 3 14:33:33 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D168721F8DCA for ; Thu, 3 Jan 2013 14:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.993 X-Spam-Level: X-Spam-Status: No, score=-99.993 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-+b1CPsNt2K for ; Thu, 3 Jan 2013 14:33:33 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 15E2521F8DC4 for ; Thu, 3 Jan 2013 14:33:32 -0800 (PST) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta02.emeryville.ca.mail.comcast.net with comcast id jZYf1k0061smiN4A2aZX4w; Thu, 03 Jan 2013 22:33:31 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta20.emeryville.ca.mail.comcast.net with comcast id jaXG1k00P52qHCY8gaXJv1; Thu, 03 Jan 2013 22:31:29 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Thu, 3 Jan 2013 14:31:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357252411; bh=0E63Q7sXqlt7YDI8a/y9kpgzq7NXCTvk3RtZ0Qu+RrA=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=RGB6ZwKeuW7XSCW/l9FYzOtcJFh/hbNsfAxnCT7qroKNgbn01XVjdSEAIgXRQcofE HZIl5ytixYneis8raJipQYTlgTyjv73TK+rmYY+LM0UiKVEsouHdslPT+ndy89p6Sx wWpy54IsuB/KE8wPogIZQLUJLop8Z80UBoT+h4jQDyYdCrMdTCn6ApIiLZZwdGevB+ 7FDXIYjLmFqooylvycx8cPkM7xVgZQ8PksexArWfUc2BsXa7+Drjurl93HRIzEZi67 rB5kmkotDRhlFK/BXBqLCzybIR/CI5FK36ybbRBUqNtEEcRroIFGt8QYcPyj0A6iXg sqQMYzAKWq08A== Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:33:33 -0000 On Jan 3, 2013, at 2:15 PM, Jeff Wheeler wrote: >>> However bad or difficult to clean up, what if that's not as bad as = the >>> alternative ? >>=20 >> Clearly, the treat-as-withdraw alternative is better. You're not = leaving bogus state in the rest of the network. >=20 > Does this mean you support treat-as-withdraw, even though you dislike > its high complexity? My read of your postings today is that you > dislike the whole error-handling idea. Jeff, I support the general concept of improved error handling and softer = failures when possible. As I've said before, errors can be reasonably classified into two = groups: syntactic and semantic. =20 A syntactic error would be any inconsistency of length fields, = incompatibility between a type and a length, or any other error that = would introduce any doubt about the parsing of the message. Once this = type of error has occurred, then the remainder of the data stream is = wholly in doubt. A session reset seems like the only (conservative) way = of handling this, as it's unclear that further data would be accurate. I'm very open to a discussion of alternatives to session flap for these = cases. Should we require manual intervention before session restart? = This would seem reasonable. Semantic errors would be consistency violations within the contents of = the message. In these cases, treat-as-withdraw seems reasonable. Tony From tony.li@tony.li Thu Jan 3 14:38:39 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8535E21F8DCF for ; Thu, 3 Jan 2013 14:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.024 X-Spam-Level: X-Spam-Status: No, score=-100.024 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SmXHfZVlai6 for ; Thu, 3 Jan 2013 14:38:39 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id 1099021F8D7F for ; Thu, 3 Jan 2013 14:38:39 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta11.emeryville.ca.mail.comcast.net with comcast id jZnu1k0021ZMdJ4ABaeeaW; Thu, 03 Jan 2013 22:38:39 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta16.emeryville.ca.mail.comcast.net with comcast id jacS1k00J52qHCY8cacVF1; Thu, 03 Jan 2013 22:36:37 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Thu, 3 Jan 2013 14:36:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <05E0568C-1A73-4F67-B484-5FB65427C563@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357252719; bh=rKDqjru0KuHWLFAjf/x13D38M5PoGvMwu3+/ukT14WA=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=CRF/pUpbCYY2n2loWPKVk//QAvRH5xoUMWTyOwdWc0o+jtD8TxxeUQ5pdeOU/sXO3 lrcCy1/vKZ+W+zES0UOWX6bmxa+Ue6hy0M9si8D9vIjLxq8FD1BiOd2ymZlsqR5PLp B/Q50LJ+EhoVXgPPPHsotXf0nxgqJfEPKJj/ofNIRxNprX2mvPzjyWzKeB6GnfOvKc j9th3MRdHQScz5I3HRfagh3z+1/t+2GUqVTPsGavddXdRQLM/gHsLHFMxHDmlq5+GE TsQvzQxHWbQvkmhQzckQ3LSJwHbFWYcN+wrXxQSyDBbKif/e4fCvHsPoJ+EcAuSBrm OT+iDqVZFBNLg== Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:38:39 -0000 On Jan 3, 2013, at 2:23 PM, Jeff Wheeler wrote: > Fortunately vendors understand that they need to produce options to > suit different kinds of customers. =20 Fortunately, this vendor has been around long enough to understand that = adding options to suit every possible behavior results in complexity in = the underlying code. We, as a collective IETF group, learned long ago = that adding 'nerd knobs' is generally a bad idea. Tony From Donald.Smith@CenturyLink.com Thu Jan 3 14:55:00 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CDD21F8DD3; Thu, 3 Jan 2013 14:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYTW+qKFHOZX; Thu, 3 Jan 2013 14:54:59 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 2B76A21F8DC5; Thu, 3 Jan 2013 14:54:59 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r03MsvHI000063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2013 15:54:58 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id B78C91E0063; Thu, 3 Jan 2013 16:54:52 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 9D1281E005D; Thu, 3 Jan 2013 16:54:52 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r03Mspk9029436; Thu, 3 Jan 2013 16:54:51 -0600 (CST) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r03MspnX029426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jan 2013 16:54:51 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0318.001; Thu, 3 Jan 2013 15:54:50 -0700 From: "Smith, Donald" To: "'Tony Li'" , "'Jeff Wheeler'" Thread-Topic: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN6gJgTRHM4SAHqUGXAu6gBw2r45g4M8pw Date: Thu, 3 Jan 2013 22:54:50 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A29EF86@PDDCWMBXEX503.ctl.intranet> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> In-Reply-To: <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'idr@ietf.org'" , "'grow@ietf.org'" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:55:00 -0000 "Pampers use multiple layers of protection to prevent leakage. Rommel used = defense in depth to defend European fortresses." (A.White) Donald.Smith@Cen= turyLink.com >-----Original Message----- >From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of >Tony Li >Sent: Thursday, January 03, 2013 3:31 PM >To: Jeff Wheeler >Cc: idr@ietf.org; grow@ietf.org >Subject: Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- >error-handling-06.txt > > >On Jan 3, 2013, at 2:15 PM, Jeff Wheeler wrote: > >>>> However bad or difficult to clean up, what if that's not as bad as >the >>>> alternative ? >>> >>> Clearly, the treat-as-withdraw alternative is better. You're not >leaving bogus state in the rest of the network. >> >> Does this mean you support treat-as-withdraw, even though you dislike >> its high complexity? My read of your postings today is that you >> dislike the whole error-handling idea. > > >Jeff, > >I support the general concept of improved error handling and softer >failures when possible. > >As I've said before, errors can be reasonably classified into two >groups: syntactic and semantic. > >A syntactic error would be any inconsistency of length fields, >incompatibility between a type and a length, or any other error that >would introduce any doubt about the parsing of the message. Once this >type of error has occurred, then the remainder of the data stream is >wholly in doubt. A session reset seems like the only (conservative) way >of handling this, as it's unclear that further data would be accurate. I disagree. Does a session reset fix the issue? It hasn't the last few time= s I have seen this. It exasperated it by causing peers to drop and having to rebuild ribs/fibs = etc... continuously. Other than getting it noticed I doubt a reset will ever make a misbehaving = router stop misbehaving. =20 > >I'm very open to a discussion of alternatives to session flap for these >cases. Should we require manual intervention before session restart? Manual intervention will be required in most cases but if we "require" manu= al intervention haven't we left the programming side (state machine) and go= ne into the operational control side of things? >This would seem reasonable. > >Semantic errors would be consistency violations within the contents of >the message. In these cases, treat-as-withdraw seems reasonable. I would also like the ignore option here. You know your neighbor is saying = something you don't understand, possibly due to a lack of in your vocabular= y but you understand other elements so you nod and continue listening to th= e rest:) This is what happened recently. ALU announced attributes with 1 bit set tha= t others didn't understand. If the routers that didn't understand that bit = could have ignored just that element everything would have been fine. > >Tony > >_______________________________________________ >GROW mailing list >GROW@ietf.org >https://www.ietf.org/mailman/listinfo/grow From tony.li@tony.li Thu Jan 3 15:17:01 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA89321F8A67 for ; Thu, 3 Jan 2013 15:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.066 X-Spam-Level: X-Spam-Status: No, score=-100.066 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPreIIZnTtXS for ; Thu, 3 Jan 2013 15:17:01 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 201F421F8770 for ; Thu, 3 Jan 2013 15:17:01 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta02.emeryville.ca.mail.comcast.net with comcast id jZJk1k0031ZMdJ4A2bH1b8; Thu, 03 Jan 2013 23:17:01 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta16.emeryville.ca.mail.comcast.net with comcast id jbEm1k00C52qHCY8cbEoHA; Thu, 03 Jan 2013 23:14:59 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <68EFACB32CF4464298EA2779B058889D0A29EF86@PDDCWMBXEX503.ctl.intranet> Date: Thu, 3 Jan 2013 15:14:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <68EFACB32CF4464298EA2779B058889D0A29EF86@PDDCWMBXEX503.ctl.intranet> To: "Smith, Donald" X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357255021; bh=vEtEtkoAVLhVqlAB0CemEyHzBUnJ50fX6BmvTPUbnGs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=fzbCBuukdJxBgt5VuMp4R3iEDMN9I1aIShUdqLs+LIvB+GMX5ZuOjztCtGKDP29Aw qM3HiZv/iPSlnaFWNGFZky7asuz5Rf4/Z6oVG9APJRVRv2MchXdR6HGXS1bcQDtwi5 4+wsFduaTE/E5y4sFU82enMqYx20q+vTUfY0tSGlXroSTUIr9R38tUSjETPpp180OY O++1qPZZfdx+ML9CT9XnPkMVJBrUmK6wx7MLsi8n60XQ1HHyM6l/3YxsJ0vFmCpn3j qs3jIxZV9oHRJvFL6+kHZWTYlzzWPf3UprteSMZ0k2WX4ltlMhSxsGGIL51qKC2Szy 303dpWayBSDzQ== Cc: "'idr@ietf.org'" , "'grow@ietf.org'" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 23:17:01 -0000 Hi Donald, >> A session reset seems like the only (conservative) way >> of handling this, as it's unclear that further data would be = accurate. > I disagree. Does a session reset fix the issue? It hasn't the last few = times I have seen this. > It exasperated it by causing peers to drop and having to rebuild = ribs/fibs etc... continuously. Which is why I suggested that re-opening the connection is perhaps not = optimal. > Other than getting it noticed I doubt a reset will ever make a = misbehaving router stop misbehaving. The point is that once you've lost context in the data stream, = subsequent messages cannot be accepted with a reasonable certainty of = correct parsing. =20 >> I'm very open to a discussion of alternatives to session flap for = these >> cases. Should we require manual intervention before session restart? > Manual intervention will be required in most cases but if we "require" = manual intervention haven't we left the programming side (state machine) = and gone into the operational control side of things? Correct. The programming side has failed. As you note, trying again is = not likely to help. Adding Artificial Intelligence to BGP to recover is = unlikely to be effective or an efficient means of making progress. >> Semantic errors would be consistency violations within the contents = of >> the message. In these cases, treat-as-withdraw seems reasonable. > I would also like the ignore option here. You know your neighbor is = saying something you don't understand, possibly due to a lack of in your = vocabulary but you understand other elements so you nod and continue = listening to the rest:) The entire problem with the ignore option is that it leaves bogus = information in the network. Suppose that the update contains an AS path = change for a prefix. If you ignore the update, then you ignore that = path change, AND, you fail to propagate that change to your upstream = neighbors. Now, BGP's loop prevention mechanism is out the window and, = in the worst case, you've created an inter-domain forwarding loop. If, on the other hand, you withdraw that prefix, then any alternate = connectivity for that prefix can come into play. In short, treat-as-withdraw is a fail safe approach. Ignoring updates = is not. Tony From brian.peter.dickson@gmail.com Thu Jan 3 15:34:49 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EF921F8D51; Thu, 3 Jan 2013 15:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbGqflifkKg5; Thu, 3 Jan 2013 15:34:48 -0800 (PST) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9B16521F8D44; Thu, 3 Jan 2013 15:34:47 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id d4so7626642eek.10 for ; Thu, 03 Jan 2013 15:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KEk3OZcEnMnCgqmTRUy9eSq7aWWFT+/VhfB/xRhOQg4=; b=E+BQcAIobEPCdbS75OSKwqKVFrnII82fzIs2fh+fESS5QxVVriT7jXJBYJcAuC9wvX YCJlgIj318+M91U32thPsUJXmXKhosngvDEp63Z3ZsOSGkxLZZ/3dodVmPGFBQGZjnn0 p0Fb1XSwhGj61wYI4aFldw3xrXyOzRAFPyVuQxK62mx+BKGcnbTHUCoupHRKVAF8M1Tw F2HR1kVtMgww5f/LeubP4JglSy5V+IcbR5NsUMWIRw2UJIHU6FBNnCGpyhDbPHqlX5cZ qPP5cb9IQhS+ixCxgspvDCQ7/MAF+U2fs2DI1rJqbq2p1A/uVsY7TXfa4g1zTXCTckXo wagg== MIME-Version: 1.0 Received: by 10.14.173.69 with SMTP id u45mr138182079eel.21.1357256069425; Thu, 03 Jan 2013 15:34:29 -0800 (PST) Received: by 10.223.173.199 with HTTP; Thu, 3 Jan 2013 15:34:29 -0800 (PST) In-Reply-To: <68EFACB32CF4464298EA2779B058889D0A29EF86@PDDCWMBXEX503.ctl.intranet> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <68EFACB32CF4464298EA2779B058889D0A29EF86@PDDCWMBXEX503.ctl.intranet> Date: Thu, 3 Jan 2013 18:34:29 -0500 Message-ID: From: Brian Dickson To: "Smith, Donald" Content-Type: multipart/alternative; boundary=047d7b6039f4e32ae604d26acdf9 Cc: "idr@ietf.org" , "grow@ietf.org" , Tony Li Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 23:34:49 -0000 --047d7b6039f4e32ae604d26acdf9 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 3, 2013 at 5:54 PM, Smith, Donald wrote: > > >-----Original Message----- > >From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of > >Tony Li > >Sent: Thursday, January 03, 2013 3:31 PM > >To: Jeff Wheeler > >Cc: idr@ietf.org; grow@ietf.org > >Subject: Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- > >error-handling-06.txt > > > > >I support the general concept of improved error handling and softer > >failures when possible. > > > It exasperated it by causing peers to drop and having to rebuild ribs/fibs > etc... continuously. > > Other than getting it noticed I doubt a reset will ever make a misbehaving > router stop misbehaving. The "continuously" points to the problem. If a session drops because of syntactic issues, it should stay down. Does that make sense? It is analogous to "treat-as-withdraw", just using a much larger hammer. :-) > >Semantic errors would be consistency violations within the contents of > >the message. In these cases, treat-as-withdraw seems reasonable. > I would also like the ignore option here. You know your neighbor is saying > something you don't understand, possibly due to a lack of in your > vocabulary but you understand other elements so you nod and continue > listening to the rest:) > > This is what happened recently. ALU announced attributes with 1 bit set > that others didn't understand. If the routers that didn't understand that > bit could have ignored just that element everything would have been fine. Here's a couple of problems with what you're suggesting here. You don't know whether that 1 bit changes the logic that should be used (e.g. "This is a back-up route only", or "Black-hole this prefix, please".) Presuming that you should use the announcement is dangerous. And then what should you do with the announcement - forward to appropriate peers, or not? If you forward it, should you keep the bit set, or not? IMHO, the safe thing to do with "unknown bit set", is treat-as-withdraw. Maybe, MAYBE, have a knob to "listen to but ignore unknown bit". DEFINITELY, do NOT announce bits you don't understand. (liberal accept, conservative send). And PROBABLY do NOT announce things if you twiddled unknown bit(s). You are potentially messing with unknown semantics, to the probable detriment of your peers. (Here there be dragons.) The safest thing is to not announce. The conservative approach is to "treat as withdraw". And put a suitable error message wherever error messages normally go. Again, IMHO. Brian --047d7b6039f4e32ae604d26acdf9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 3, 2013 at 5:54 PM, Smith, D= onald <Donald.Smith@centurylink.com> wrote:
>-----Original Message-----
>From: = grow-bounces@ietf.org [mailto:= grow-bounces@ietf.org] On Behalf Of
>Tony Li
>Sent: Thursday, January 03, 2013 3:31 PM
>To: Jeff Wheeler
>Cc: idr@ietf.org; grow@ietf.org
>Subject: Re: [GROW] [Idr] I-D Action: draf= t-ietf-grow-ops-reqs-for-bgp-
>error-handling-06.txt
>

>I support the general concept of improved error handling and softer
>failures when possible.
>
It exasperated it by causing peers to drop and having to rebuild ribs/fibs = etc... continuously.

Other than getting it noticed I doubt a reset will ever make a misbehaving = router stop misbehaving.

The "continuo= usly" points to the problem. If a session drops because of syntactic i= ssues, it should stay down.
Does that make sense? It is analogous to "treat-as-withdraw"= , just using a much larger hammer. :-)
=A0
>Semantic errors would be consistency violations within the contents of<= br> >the message. =A0In these cases, treat-as-withdraw seems reasonable.
I would also like the ignore option here. You know your neighbor is s= aying something you don't understand, possibly due to a lack of in your= vocabulary but you understand other elements so you nod and continue liste= ning to the rest:)

This is what happened recently. ALU announced attributes with 1 bit set tha= t others didn't understand. If the routers that didn't understand t= hat bit could have ignored just that element everything would have been fin= e.

Here's a couple of problems with what you're su= ggesting here.

You don't know whether that 1 b= it changes the logic that should be used (e.g. "This is a back-up rout= e only", or "Black-hole this prefix, please".)
Presuming that you should use the announcement is dangerous.

And then what should you do with the announcement - forward= to appropriate peers, or not?
If you forward it, should you keep= the bit set, or not?

IMHO, the safe thing to do with "unknown bit set&q= uot;, is treat-as-withdraw.

Maybe, MAYBE, have a k= nob to "listen to but ignore unknown bit".

DEFINITELY, do NOT announce bits you don't understand. (liberal ac= cept, conservative send).

And PROBABLY do NOT anno= unce things if you twiddled unknown bit(s).
You are potentially m= essing with unknown semantics, to the probable detriment of your peers.
(Here there be dragons.)

The safest thing is = to not announce. The conservative approach is to "treat as withdraw&qu= ot;.
And put a suitable error message wherever error messages nor= mally go.

Again, IMHO.

Brian
--047d7b6039f4e32ae604d26acdf9-- From jared@puck.nether.net Thu Jan 3 15:42:16 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8579921F8CA1; Thu, 3 Jan 2013 15:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f2uNVT49OfZ; Thu, 3 Jan 2013 15:42:15 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8C421F8830; Thu, 3 Jan 2013 15:42:15 -0800 (PST) Received: from [10.0.0.129] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id r03Ng6mk026413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jan 2013 18:42:07 -0500 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: Date: Thu, 3 Jan 2013 18:42:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <68EFACB32CF4464298EA2779B058889D0A29EF86@PDDCWMBXEX503.ctl.intranet> To: Brian Dickson X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 03 Jan 2013 18:42:07 -0500 (EST) Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 23:42:16 -0000 On Jan 3, 2013, at 6:34 PM, Brian Dickson = wrote: >=20 >=20 > On Thu, Jan 3, 2013 at 5:54 PM, Smith, Donald = wrote: > >-----Original Message----- > >From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf = Of > >Tony Li > >Sent: Thursday, January 03, 2013 3:31 PM > >To: Jeff Wheeler > >Cc: idr@ietf.org; grow@ietf.org > >Subject: Re: [GROW] [Idr] I-D Action: = draft-ietf-grow-ops-reqs-for-bgp- > >error-handling-06.txt > > >=20 > >I support the general concept of improved error handling and softer > >failures when possible. > > > It exasperated it by causing peers to drop and having to rebuild = ribs/fibs etc... continuously. >=20 > Other than getting it noticed I doubt a reset will ever make a = misbehaving router stop misbehaving. >=20 > The "continuously" points to the problem. If a session drops because = of syntactic issues, it should stay down. > Does that make sense? It is analogous to "treat-as-withdraw", just = using a much larger hammer. :-) >=20 I think that Mike Long had it right earlier today in saying that the = vendor implementation should shut the session just like max-prefix. = (perhaps with a default restart-timer measured in tens of minutes)? = This doesn't seem to need a protocol change though. I am also a bit = wary of as Tony put it .. "nerd knobs". I've seen how some of these = legacy knobs break in some new/future release as they migrate through = our templates/platforms over the years. Nobody even knows what it does = anymore, and the original purpose is gone but the parser still takes it = ... - Jared= From randy@psg.com Thu Jan 3 15:48:30 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA7521F8E04; Thu, 3 Jan 2013 15:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xzMxl7OmTUj; Thu, 3 Jan 2013 15:48:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 547D921F8E03; Thu, 3 Jan 2013 15:48:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TquWS-0004Te-6D; Thu, 03 Jan 2013 23:48:28 +0000 Date: Fri, 04 Jan 2013 08:48:26 +0900 Message-ID: From: Randy Bush To: Tony Li In-Reply-To: <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , grow Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 23:48:30 -0000 > A syntactic error would be any inconsistency of length fields, > incompatibility between a type and a length, or any other error that > would introduce any doubt about the parsing of the message. Once this > type of error has occurred, then the remainder of the data stream is > wholly in doubt. A session reset seems like the only (conservative) > way of handling this, as it's unclear that further data would be > accurate. both ears > I'm very open to a discussion of alternatives to session flap for > these cases. Should we require manual intervention before session > restart? This would seem reasonable. you may have more faith in the alacrity of manual response than i > Semantic errors would be consistency violations within the contents of > the message. In these cases, treat-as-withdraw seems reasonable. and the tail randy From jsw@inconcepts.biz Thu Jan 3 16:26:42 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269E921F8480 for ; Thu, 3 Jan 2013 16:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43ySLRSmpLsK for ; Thu, 3 Jan 2013 16:26:41 -0800 (PST) Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) by ietfa.amsl.com (Postfix) with ESMTP id F1F2E21F846B for ; Thu, 3 Jan 2013 16:26:40 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id t4so13093536iag.39 for ; Thu, 03 Jan 2013 16:26:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=TjaqyWNdofijDgTJwDCFBZ+mugYQd48wzXcNvh2e3C0=; b=KVVQb+kHuq/+sJrHC8vV/4tJ4/h7ezIJMpSfpQ48A60byXPpCAtkJDZr7Rb83nE+la cPe0k/9M4Qv8QeX9RGXGxO9yyhY10oi7mJs1vfMvQojosgXqg6TqbVjzYgkJUZqHQh3S F15lVgtJMK/m+wWSatUJmTIlng1F/Dr7+quqvCs3rw0H+XLFVHa8PnvnZM0kjOpRjatK qjoKzjk62L0SQ66GHiF5krQUHynI9tL96tY5meaf4d6QZmX8Jnov1+a+jVLtsC39+pSd OgOTD4V3otegKmsJaU6u7TDZ1BQ7Imx+w9TydIsC8BAnwnyEeMADgV4W02eqbcHXxsL0 YTow== MIME-Version: 1.0 Received: by 10.50.104.232 with SMTP id gh8mr43175350igb.45.1357259200448; Thu, 03 Jan 2013 16:26:40 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 3 Jan 2013 16:26:40 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> Date: Thu, 3 Jan 2013 19:26:40 -0500 Message-ID: From: Jeff Wheeler To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl1jB9I8U532aVhZp9207LXqWJzozreTanFTCXa6kkvhATqE2K8aiXg67ffqiCWmGICM/aB Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 00:26:42 -0000 On Thu, Jan 3, 2013 at 5:31 PM, Tony Li wrote: > A syntactic error would be any inconsistency of length fields, incompatib= ility between a type and a length, or any other error that would introduce = any doubt about the parsing of the message. Once this type of error has oc= curred, then the remainder of the data stream is wholly in doubt. A sessio= n reset seems like the only (conservative) way of handling this, as it's un= clear that further data would be accurate. > > I'm very open to a discussion of alternatives to session flap for these c= ases. Should we require manual intervention before session restart? This = would seem reasonable. I've already posted an alternative. The BGP MARKER makes it possible to recover Message framing. I'm not sure I think this is a good idea. I am sure I would wish for it at 2am on a Saturday morning, if it fixed my problem. So if my vendor supplied it as an option, I might be glad for that someday. > Semantic errors would be consistency violations within the contents of th= e message. In these cases, treat-as-withdraw seems reasonable. The current draft for "treat-as-withdraw" has a great deal of complexity. You seem to both favor this solution, and hate the complexity. I also hate the complexity, and "ignore-bad-message" is my alternative. Would you rather the draft simply eliminate a lot of the complexity? I would, because the complexity is what creates more opportunities for session-reset. It also may catalyze bugs. None of these are "nerd knobs" when they fix your operational problem and allow you to stop bleeding money. TCP Path MTU Detection for BGP is a "nerd knob." Yet, there it is, along with plenty of other things that might tweak your router a bit; but they're not there to save your butt in a crisis. That's what error-handling should do -- save your butt. On Thu, Jan 3, 2013 at 5:54 PM, Smith, Donald wrote: > Other than getting it noticed I doubt a reset will ever make a misbehavin= g router stop misbehaving. Maybe not, but I've certainly seen it solve problems. For example, Cisco 6500/7600s used to send > MTU sized Ethernet frames to eBGP neighbors if TCP MD5 for BGP was in use. I had a eBGP session to a transit network which would fail every few days because the Cisco box would repeatedly try to send an illegally-large frame, my router would discard the frames, and the Cisco would keep trying to retransmit it. Eventually my HoldTime would expire. As you might imagine, this took quite some time for us to diagnose; but at least the auto-reset caused the network to return to a good state pretty quickly. > This is what happened recently. ALU announced attributes with 1 bit set t= hat others didn't understand. If the routers that didn't understand that bi= t could have ignored just that element everything would have been fine. Actually the problematic routers that reset their sessions "MUST have ignored [this bit] when received," according to RFC4271, but they didn't do that. So the reason why those routers broke is that THEY were buggy AND the originating router was buggy. It is also arguable that routers in the DFZ should not have propagated this 1 bit. Some routers didn't while others did. So if the receiving routers weren't buggy in the first place, they would not have experienced any problem. However, ignore-bad-message or treat-as-withdraw would be a good catch-all that an operator could use, even if his router was buggy, to keep his network functioning. On Thu, Jan 3, 2013 at 6:14 PM, Tony Li wrote: > The entire problem with the ignore option is that it leaves bogus informa= tion in the network. Suppose that the update contains an AS path change fo= r a prefix. If you ignore the update, then you ignore that path change, AN= D, you fail to propagate that change to your upstream neighbors. Now, BGP'= s loop prevention mechanism is out the window and, in the worst case, you'v= e created an inter-domain forwarding loop. > > If, on the other hand, you withdraw that prefix, then any alternate conne= ctivity for that prefix can come into play. > > In short, treat-as-withdraw is a fail safe approach. Ignoring updates is= not. Treat-as-withdraw is NOT fail-safe. It can create loops or blackholes in your network. Claiming over and over that it is safe will not make it true. Ignore-bad-message has bad qualities, which are just as bad as treat-as-withdraw, except it is less complicated to implement and there is a greater chance it can avoid a potentially crippling session-reset loop. --=20 Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From tony.li@tony.li Thu Jan 3 17:04:04 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B7E21F8E1D for ; Thu, 3 Jan 2013 17:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.092 X-Spam-Level: X-Spam-Status: No, score=-100.092 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgT9RW8FF1Sp for ; Thu, 3 Jan 2013 17:04:04 -0800 (PST) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB9F21F8E11 for ; Thu, 3 Jan 2013 17:04:04 -0800 (PST) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta07.emeryville.ca.mail.comcast.net with comcast id jcpo1k0041wfjNsA7d44x8; Fri, 04 Jan 2013 01:04:04 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta23.emeryville.ca.mail.comcast.net with comcast id jd1q1k01352qHCY8jd1tlV; Fri, 04 Jan 2013 01:02:02 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Thu, 3 Jan 2013 17:01:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357261444; bh=ycB8dX8P6kAOT5ESsxaX6j/7upJa3DOyoK10RrDk9xQ=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=EslPQRQ/tybIx3CRPXA4QOFqhcUwjee4NkjCeHRIVLqdC2TrmRCXF8kyUyt7ZpJcH WWBYmt3fRKo+O/2Yj5xvlan7jZ7aHl1YKzF+WdBOnTStB/m1cLvymHUQrWJchyWkz+ qHqvIHlUhhcKk2GT6uWb3MuycyRzNDrpm3Bz3hTjGwkWLZRtUZ8HJGioBndWslnvue 3rj6aSwLRY2xB/YSCOiZQV9GRk4BglzZeNX6SjrIc0amC2iqr7XG+lFNSQ6Tp/NMmA xf78jqUSYE1aGl7VYEhVdiY97mzChry+MesQYoe6t7PXeeYkhaDlraQS9+5ZuTVzo/ RtrqBa3DUNbjA== Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 01:04:04 -0000 Hi Jeff, > I've already posted an alternative. The BGP MARKER makes it possible > to recover Message framing. I'm not sure I think this is a good idea. I'm pretty convinced that it's NOT a good idea. What happens if the = marker is preceded by 0xFF? Ok, you can make some educated guesses = based on what looks to be a length field (probably NOT starting with = 0xFF), but you are just guessing. =20 And what if the error was egregious and your parsing is off by more than = a byte or two? That marker might be a path attribute. Now what? Ok, yes, you could take a risk and see if you can keep parsing, but then = what happens if you hit another error? Just keep guessing along? Your = odds of guessing correctly are falling. Or do you try to be really, = really smart? While you may be willing to gamble with your domain, please remember = that you are also gambling with every network that accepts updates from = you, transitively. For lots of folks, that's the bulk of the Internet. = Is this a good gamble? I'm not convinced. >> Semantic errors would be consistency violations within the contents = of the message. In these cases, treat-as-withdraw seems reasonable. >=20 > The current draft for "treat-as-withdraw" has a great deal of > complexity. You seem to both favor this solution, and hate the > complexity. I also hate the complexity, and "ignore-bad-message" is > my alternative. To be specific, treat-as-withdraw seems to be less dangerous. As = implemented (and perhaps NOT as envisioned), treat-as-withdraw can be = done with an acceptable amount of complexity, IMHO. It needs to be done = VERY simply. > Would you rather the draft simply eliminate a lot of the complexity? > I would, because the complexity is what creates more opportunities for > session-reset. It also may catalyze bugs. I would welcome that, but we should recognize that we're making a = tradeoff. 4271 opts for maximum simplicity: if there's an error, shut = it down. Anything more than that will be added complexity. What we're = trying to do is to add some small amounts of complexity for a hopefully = significant amount of robustness. If done right, that would be a = reasonable tradeoff. If done wrong, this could be a major disaster. >> The entire problem with the ignore option is that it leaves bogus = information in the network. Suppose that the update contains an AS path = change for a prefix. If you ignore the update, then you ignore that = path change, AND, you fail to propagate that change to your upstream = neighbors. Now, BGP's loop prevention mechanism is out the window and, = in the worst case, you've created an inter-domain forwarding loop. >>=20 >> If, on the other hand, you withdraw that prefix, then any alternate = connectivity for that prefix can come into play. >>=20 >> In short, treat-as-withdraw is a fail safe approach. Ignoring = updates is not. >=20 > Treat-as-withdraw is NOT fail-safe. It can create loops or blackholes > in your network. Claiming over and over that it is safe will not make > it true. Example please? Assuming that the prefixes are parsed out of the = message correctly, then treating them as withdrawn should be hazard = free. > Ignore-bad-message has bad qualities, which are just as bad as > treat-as-withdraw, except it is less complicated to implement and > there is a greater chance it can avoid a potentially crippling > session-reset loop. Non-sequitur. Cyclic resets are orthogonal to treat-as-withdraw. As = enumerated above, ignore-bad-message is harder to implement and is more = dangerous. =20 Tony From jsw@inconcepts.biz Thu Jan 3 18:33:50 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1761721F8E52 for ; Thu, 3 Jan 2013 18:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBcNtcmaVH3J for ; Thu, 3 Jan 2013 18:33:49 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBBC21F8E50 for ; Thu, 3 Jan 2013 18:33:49 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id k10so19589111iea.29 for ; Thu, 03 Jan 2013 18:33:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=kyffh7qcBoFlHR2kP0VkO8PghPZC8cvUxl752tq87dc=; b=ha68S3Zza/QQ1vKhKhWmuqYFAsPRGBgsDa2mnHlRwRTir4a9bDoNRRYV5fArkhXovF gVBPJ/qW+qX1S2lq6hyVOeFUCxAWFnO2bd8oaMHLmqinzQOd/MbC94g+yb8YJ1IQQxHX SGwy4REhcZ4zQJuHpE8P6zqxPqDnoONpyBgpa5+VamQGF4j1OtzFB9v5V6nli5qYZtgj 90HmB1uZI9i2xLsrWcYSMSGuyN6c3DKNUH/je44562BRBG06tZf5Lm+uNHRL/LEzly9M T5SK43p/xm49ksFbPlVZxScSXkcf9i/pEjnDzji/35Z+EHOMKgbdDQjtnvU+yeSkhPdn /XtQ== MIME-Version: 1.0 Received: by 10.50.104.232 with SMTP id gh8mr43361657igb.45.1357266828863; Thu, 03 Jan 2013 18:33:48 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 3 Jan 2013 18:33:48 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> Date: Thu, 3 Jan 2013 21:33:48 -0500 Message-ID: From: Jeff Wheeler To: Tony Li Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmv8ifsZmxnGStn1wILs0WX8nSq6VRavFM4QukEx60IN0Htoc7/+kb2AXfJ8BFJifFhZlr+ Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 02:33:50 -0000 On Thu, Jan 3, 2013 at 8:01 PM, Tony Li wrote: > Example please? Assuming that the prefixes are parsed out of the message correctly, then treating them as withdrawn should be hazard free. If a transit router in your AS treats-as-withdraw a prefix, other routers may try to send traffic across it, but the router which has treated-as-withdraw will either have no information for that route, or it will have made a different bestpath choice. This could cause a loop or a blackhole. > Non-sequitur. Cyclic resets are orthogonal to treat-as-withdraw. As enumerated above, ignore-bad-message is harder to implement and is more dangerous. No, ignore-bad-message is not harder to implement. To say so is simply a lie. To treat-as-withdraw you have to follow some rules, parse a damaged message to look for NLRI, and then withdraw them. Treat-as-withdraw is unquestionably harder than simply ignoring the whole contents of a message. Your argument is some hand-waving about how hard it is to ignore a message, and your incorrect belief that treat-as-withdraw can't leave the RIB in state that can cause forwarding problems. I'm not picking at your position just for the sake of argument. I agree with you that error-handling (current draft) is too complicated. I'm suggesting alternatives, as well as modifications that should be made to either RFC4760bis or to error-handling to make it actually work. Just to move beyond ignore-bad-message vs. treat-as-withdraw arguments for now, I believe some basic questions need to be answered for treat-as-withdraw to be a useful option. 1) should a BGP speaker be able to promise that MP attributes will be sent first? if so, a capability code is needed this could be done by error-handling or RFC4760bis 2) should non-MP NLRIs in the message be moved in the way error-handling suggests? if so, a capability is absolutely required the basic encoding of BGP Messages changes if this is to be done 3) there are numerous attribute-specific rules in error-handling now. They are not crazy but they are complicated. Is this complexity enough to deter vendors from implementing error-handling at all? Are they likely to catalyze bugs? Do the attribute-specific rules do more harm than good? If you are in favor of treat-as-withdraw then the above are important questions to answer. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From sairay@cisco.com Thu Jan 3 18:37:19 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9D121F8E4E; Thu, 3 Jan 2013 18:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjfHA39+lWAs; Thu, 3 Jan 2013 18:37:18 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B734421F88B2; Thu, 3 Jan 2013 18:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1115; q=dns/txt; s=iport; t=1357267039; x=1358476639; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QuiKMeOUxFe9uZZwkNKy2sXtCehC/53JwBeRFzi9M7g=; b=mHeyOS2ErcWnJlpmHy/X4S/6FxDIhJEzN5INLX+pcJwbYdXf/G3BV5wW ent8VLIjrJMP+/KmiiHyhvx3nU5xUP1PfUDEZWKgwY5HeMSLMX39avBbZ lJBL2E0lGi2wSlf/dynUY7ICddbDq6CE8GPGseSlaK32RpHdmzj+GkrzF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJE/5lCtJXHA/2dsb2JhbABFvUwWc4IeAQEBBDo/DAQCAQgOAwQBAQEKFAkHMhQJCAIEAQ0FCIgKAbZxkDlhA6ZUgnSBaAc3 X-IronPort-AV: E=Sophos;i="4.84,406,1355097600"; d="scan'208";a="158719339" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 04 Jan 2013 02:37:18 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r042bHYk010453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 02:37:18 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.77]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 20:37:17 -0600 From: "Saikat Ray (sairay)" To: Jeff Wheeler , Tony Li Thread-Topic: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN6iP9zU1iOSP0s0au+0QHwDr5iJg4c+tQ Date: Fri, 4 Jan 2013 02:37:16 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.139.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 02:37:19 -0000 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeff = Wheeler Sent: Thursday, January 03, 2013 6:34 PM To: Tony Li Cc: idr@ietf.org; grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-erro= r-handling-06.txt On Thu, Jan 3, 2013 at 8:01 PM, Tony Li wrote: > Example please? Assuming that the prefixes are parsed out of the message= correctly, then treating them as withdrawn should be hazard free. If a transit router in your AS treats-as-withdraw a prefix, other routers m= ay try to send traffic across it, but the router which has treated-as-withd= raw will either have no information for that route, or it will have made a = different bestpath choice. This could cause a loop or a blackhole. [SR] If the transit router treated the prefix as "withdrawn", then it will = remove the corresponding path. If there are no other paths for that net, th= en the router would send withdraws for that prefix to its own peers. So no = other router would send traffic to it in the steady state. From jsw@inconcepts.biz Thu Jan 3 18:48:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E7821F8DFF for ; Thu, 3 Jan 2013 18:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MEXv3XSV90q for ; Thu, 3 Jan 2013 18:48:36 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD5621F8DBD for ; Thu, 3 Jan 2013 18:48:36 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so19090972iea.24 for ; Thu, 03 Jan 2013 18:48:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=a9iEo2bBz8vgUqyh1ntqrao1f0Lgo1OZdYImHhMiQHw=; b=bGHjNY3/2DrknXq/gJVb5xLubeqASinL0NNcM4SfNbeI8bk7kIwQHKV/WheaWtnf8O X91Py/wrTvvEg4LlLSmE6SHbyLLbQYZ/ls52WowYr6gFYtFlx7TraFMudXvhtYZUwNMK 2pjGeETA8W19O2iB/P+1S7PE/Qe+PMGl6EbAoCoH0mYWDbdXuDo7xw3uRCPow0LbIKIo 7i5Ea99vDZUIxwkj3PVksM9xEAY3yX5BcHKYEq1cRx9Vij0Hzla/kOJQI4zpP3MjhYz0 LcEOVu5VvKSbAB5LPRCdJiRjpvcGuowF7Egd4kBBfjLoZ5Pku6E51p23Q40IGTXAmw57 oETw== MIME-Version: 1.0 Received: by 10.50.104.232 with SMTP id gh8mr43382290igb.45.1357267715845; Thu, 03 Jan 2013 18:48:35 -0800 (PST) Received: by 10.64.132.33 with HTTP; Thu, 3 Jan 2013 18:48:35 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> Date: Thu, 3 Jan 2013 21:48:35 -0500 Message-ID: From: Jeff Wheeler To: "Saikat Ray (sairay)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlT6U5tkvxMAfqWtNY6VdjRX5fLrJRSdZFFIBPXBmsJndad0NaAulVbmzujpfp/3Cy74VS1 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 02:48:36 -0000 On Thu, Jan 3, 2013 at 9:37 PM, Saikat Ray (sairay) wrot= e: > If a transit router in your AS treats-as-withdraw a prefix, other routers= may try to send traffic across it, but the router which has treated-as-wit= hdraw will either have no information for that route, or it will have made = a different bestpath choice. This could cause a loop or a blackhole. > > [SR] If the transit router treated the prefix as "withdrawn", then it wil= l remove the corresponding path. If there are no other paths for that net, = then the router would send withdraws for that prefix to its own peers. So n= o other router would send traffic to it in the steady state. Perhaps you read "ASBR" where in fact I wrote "transit router?" The behavior you describe is wrong. --=20 Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From sairay@cisco.com Thu Jan 3 18:53:16 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FD621F8E8C; Thu, 3 Jan 2013 18:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OmXGtj+r0vC; Thu, 3 Jan 2013 18:53:15 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1C53421F8E69; Thu, 3 Jan 2013 18:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1799; q=dns/txt; s=iport; t=1357267987; x=1358477587; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=evAURXRPjF8Fx9mtuu8IeJgFq2CJJHFbQx8oXWQTD58=; b=PWqFm/Lm4iFpamwGP8hUnJY/ciWtm1Gq7cXbAMBWnpZTbpZM84Ro/EZE 7Y6ODj3t6j2T/pJgi8nNwrywziLg4OX+zVsZJYNv/zyXef7jnGaczGizi Ak2uWZa0/lChqu8LjrsQA/R/wYtzdAG4kXt53F67A09vX/YL7Zg2f5osU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIFD5lCtJXHB/2dsb2JhbABFvUwWc4IeAQEBBDo/DAQCAQgOAwQBAQEKFAkHMhQJCAIEDgUIiAoBtnOQOWEDplSCdIFoBzc X-IronPort-AV: E=Sophos;i="4.84,406,1355097600"; d="scan'208";a="158507013" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jan 2013 02:53:06 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r042r6dM027556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 02:53:06 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.77]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 20:53:06 -0600 From: "Saikat Ray (sairay)" To: Jeff Wheeler Thread-Topic: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN6iX+pP5muDGR70G7eUwvXv72hJg4d8fg Date: Fri, 4 Jan 2013 02:53:05 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.139.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 02:53:16 -0000 -----Original Message----- From: Jeff Wheeler [mailto:jsw@inconcepts.biz]=20 Sent: Thursday, January 03, 2013 6:49 PM To: Saikat Ray (sairay) Cc: idr@ietf.org; grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-erro= r-handling-06.txt On Thu, Jan 3, 2013 at 9:37 PM, Saikat Ray (sairay) wrot= e: > If a transit router in your AS treats-as-withdraw a prefix, other routers= may try to send traffic across it, but the router which has treated-as-wit= hdraw will either have no information for that route, or it will have made = a different bestpath choice. This could cause a loop or a blackhole. > > [SR] If the transit router treated the prefix as "withdrawn", then it wil= l remove the corresponding path. If there are no other paths for that net, = then the router would send withdraws for that prefix to its own peers. So n= o other router would send traffic to it in the steady state. Perhaps you read "ASBR" where in fact I wrote "transit router?" The behavi= or you describe is wrong. [SR] Wrong in what sense? BGP code does not care whether it is a transit or= an ASBR. What I described is exactly what the code will do. (i) a path for a prefix (a "net") is withdrawn. (ii) BGP deletes the path from that net. (iii) BGP reruns bestpath computation. (iv) If the bestpath changes,=20 (a) if there is a new bestpath, then BGP readvertises t= he new bestpath to all its peers (b) if there is no bestpath (which would be the case wh= en there is no path for the net), BGP will send withdraws to all its peers. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From tony.li@tony.li Thu Jan 3 18:56:27 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C57F21F8EA8 for ; Thu, 3 Jan 2013 18:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.11 X-Spam-Level: X-Spam-Status: No, score=-100.11 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCyomKQrTc3N for ; Thu, 3 Jan 2013 18:56:27 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 1A64A21F8E94 for ; Thu, 3 Jan 2013 18:56:27 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta02.emeryville.ca.mail.comcast.net with comcast id jWUj1k0031ZMdJ4A2ewTH0; Fri, 04 Jan 2013 02:56:27 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta16.emeryville.ca.mail.comcast.net with comcast id jeuE1k00A52qHCY8ceuGPr; Fri, 04 Jan 2013 02:54:25 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Thu, 3 Jan 2013 18:54:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6737CEC8-E3CF-419B-84BF-8713CB67D709@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357268187; bh=euXDSWnq3cK4jTWcumRYHFy2ERyVePBZ+cvLfiq0qmg=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=QaplJoQTflm8g+rK05F8gLLRTRC/X23x5hINNrIMc1yIDK0J8XmwXmoLEqKvhVkNN EI3nA5TRASAxJxU7KasTtQoh/UL8XT5n9LFuYGClaCurXrrH/HzO/JHDpFICoQ1tZn xE1kFRYxLAyqDquR9yj7o0WrmAuBxJuAiGoMk6krs2BSrtyfQiLM7FM86mLqHHVtBv TbtQT0Mj6ThKBZmM0ni+BO0XnWlxACnaXvbZphnrjttRPfj57wIXOh8zsc9Fu5cFbl eazhUyTOnNmmkyIP8+ZaYsppypkj0/BjVZB83xS6DE9RYDUiaYbf0fkU25cqapV3kO v8Ry0HBDlirpQ== Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 02:56:27 -0000 On Jan 3, 2013, at 6:33 PM, Jeff Wheeler wrote: >> Non-sequitur. Cyclic resets are orthogonal to treat-as-withdraw. As = enumerated above, ignore-bad-message is harder to implement and is more = dangerous. >=20 > No, ignore-bad-message is not harder to implement. To say so is = simply a lie. I'm sorry, but this conversation has taken a turn for the worse. I may = be wrong (I really don't think so), but I am not lying. You owe me an apology and I'm not going to continue this conversation = until you do. Tony From john@jlc.net Thu Jan 3 19:14:15 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B121F8E4B for ; Thu, 3 Jan 2013 19:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a47FZzKcqxH for ; Thu, 3 Jan 2013 19:14:15 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id CC86721F8E3E for ; Thu, 3 Jan 2013 19:14:14 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0156133D85; Thu, 3 Jan 2013 22:14:14 -0500 (EST) Date: Thu, 3 Jan 2013 22:14:14 -0500 From: John Leslie To: Jeff Wheeler Message-ID: <20130104031414.GE25817@verdi> References: <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: idr@ietf.org Subject: [Idr] ACK/NAK (was ...reqs-for-bgp-error-handling) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 03:14:15 -0000 Jeff Wheeler wrote: > > > > Treat-as-withdraw is NOT fail-safe. It can create loops or blackholes > in your network. Claiming over and over that it is safe will not make > it true. Actually, this is true -- it's just _safer_... > Ignore-bad-message has bad qualities, which are just as bad as > treat-as-withdraw, except it is less complicated to implement and > there is a greater chance it can avoid a potentially crippling > session-reset loop. We seem to be getting nowhere -- rather few of us are willing to consent to what Jeff wants. Let me try a different tack: - were we designng BGP from scratch, we'd probably include ACK/NAK; - it's not comfortable to retrofit ACK/NAK; - but is it even _possible_? Perhaps it is... Were I designing BGP with ACK/NAK: - I'd send ACK/NAK for every UPDATE, perhaps batched; - if I NAK a message, it means I've completely discarded it; - the original sender MUST re-send any withdraws; - the original sender MAY retry any NLRI in simpler form. In order to be certain the ACK/NAK matches the correct UPDATE: - each UPDATE needs an ID field associated with it. One possible way to retrofit would include: - each peer advertises the capability to receive ACK/NAK; - each peer advertises the capability to send ACK/NAK; The capability to receive ACK/NAK includes: - ability to act upon the ACK/NAK message type; - ability to send a (new) SEQNUM message type. The capability to send ACK/NAK includes: - ability to recognize the SEQNUM message type; - ability to send the ACK/NAK message type. Were we to standardize something along these lines, Jeff could: - advertise capability to send ACK/NAK; - if peer advertises capability to receive ACK/NAK: - keep a running SEQNUM; - send ACK/NAK with SEQNUM immediately preceding; - safely discard any message it NAKs; - otherwise send NOTIFY and close the session. Logging the NAKs would be helpful but not essential. ==== I am frankly uninterested in why Jeff doesn't like this; I am interested in hearing any better way to accomplish a safe discard of UPDATE messages -- I'm even interested in hearing if multiple flavors of ACK would be helpful, and what additional information we might send along with a NAK. (It's probably premature to discuss how a sender might send "in simpler form" -- but that _is_ an interesting topic...) While it seems impolite to advertise the capability to send ACK/NAK without also advertising the capability to receive them, I think it better to allow one without the other. The capability to receive ACK/NAK implies at a minimum storing withdrawn-route information until you receive the ACK/NAK. Of course, sending ACK/NAK to a peer that didn't advertise the capability to receive it deserves an immediate NOTIFY; and sending SEQNUM to a peer that didn't advertise the capability to send ACK/NAK probably deserves the same. -- John Leslie From jakob.heitz@ericsson.com Thu Jan 3 22:23:46 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF23521F8D71 for ; Thu, 3 Jan 2013 22:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOeEisoFBgNe for ; Thu, 3 Jan 2013 22:23:45 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFDA21F8834 for ; Thu, 3 Jan 2013 22:23:44 -0800 (PST) Received: from EUSAAHC008.ericsson.se ([147.117.188.96]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r046YQDB024304; Fri, 4 Jan 2013 00:37:37 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 01:23:10 -0500 From: Jakob Heitz To: John Leslie , Jeff Wheeler Thread-Topic: [Idr] ACK/NAK (was ...reqs-for-bgp-error-handling) Thread-Index: AQHN6imeAmuB0b8DEk+wDOKVvtHIq5g4sgtQ Date: Fri, 4 Jan 2013 06:23:09 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14D1DF@eusaamb109.ericsson.se> References: <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <20130104031414.GE25817@verdi> In-Reply-To: <20130104031414.GE25817@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] ACK/NAK (was ...reqs-for-bgp-error-handling) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 06:23:46 -0000 When does an router NAK or ACK? After parsing? after running policy? after installation in the BGP loc-RIB? after installing in the FIB? after doing route selection? It is not just parsing errors that cause session resets. We can not reliably know when to ACK to make sure all bugs are covered. On , John Leslie <> wrote: > Jeff Wheeler wrote: >>=20 >> >>=20 >> Treat-as-withdraw is NOT fail-safe. It can create loops or >> blackholes in your network. Claiming over and over that it is safe >> will not make it true. >=20 > Actually, this is true -- it's just _safer_... >=20 >> Ignore-bad-message has bad qualities, which are just as bad as >> treat-as-withdraw, except it is less complicated to implement and >> there is a greater chance it can avoid a potentially crippling >> session-reset loop. >=20 > We seem to be getting nowhere -- rather few of us are willing to > consent to what Jeff wants.=20 >=20 > Let me try a different tack: >=20 > - were we designng BGP from scratch, we'd probably include ACK/NAK; > - it's not comfortable to retrofit ACK/NAK; > - but is it even _possible_? >=20 > Perhaps it is... >=20 > Were I designing BGP with ACK/NAK: >=20 > - I'd send ACK/NAK for every UPDATE, perhaps batched; > - if I NAK a message, it means I've completely discarded it; > - the original sender MUST re-send any withdraws; > - the original sender MAY retry any NLRI in simpler form. >=20 > In order to be certain the ACK/NAK matches the correct UPDATE: >=20 > - each UPDATE needs an ID field associated with it. >=20 > One possible way to retrofit would include: >=20 > - each peer advertises the capability to receive ACK/NAK; > - each peer advertises the capability to send ACK/NAK; >=20 > The capability to receive ACK/NAK includes: >=20 > - ability to act upon the ACK/NAK message type; > - ability to send a (new) SEQNUM message type. >=20 > The capability to send ACK/NAK includes: >=20 > - ability to recognize the SEQNUM message type; > - ability to send the ACK/NAK message type. >=20 > Were we to standardize something along these lines, Jeff could: >=20 > - advertise capability to send ACK/NAK; > - if peer advertises capability to receive ACK/NAK: > - keep a running SEQNUM; > - send ACK/NAK with SEQNUM immediately preceding; > - safely discard any message it NAKs; > - otherwise send NOTIFY and close the session. >=20 > Logging the NAKs would be helpful but not essential. >=20 > =3D=3D=3D=3D >=20 > I am frankly uninterested in why Jeff doesn't like this; I am > interested in hearing any better way to accomplish a safe discard > of UPDATE messages -- I'm even interested in hearing if multiple > flavors of ACK would be helpful, and what additional information > we might send along with a NAK. >=20 > (It's probably premature to discuss how a sender might send > "in simpler form" -- but that _is_ an interesting topic...) >=20 > While it seems impolite to advertise the capability to send > ACK/NAK without also advertising the capability to receive them, > I think it better to allow one without the other. The capability > to receive ACK/NAK implies at a minimum storing withdrawn-route > information until you receive the ACK/NAK. >=20 > Of course, sending ACK/NAK to a peer that didn't advertise the > capability to receive it deserves an immediate NOTIFY; and sending > SEQNUM to a peer that didn't advertise the capability to send ACK/NAK > probably deserves the same. --=20 Jakob Heitz. From jsw@inconcepts.biz Thu Jan 3 22:41:44 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BE821F869B for ; Thu, 3 Jan 2013 22:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lu1MLaAOtQ1 for ; Thu, 3 Jan 2013 22:41:43 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 907F221F8692 for ; Thu, 3 Jan 2013 22:41:43 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id h16so14881220oag.33 for ; Thu, 03 Jan 2013 22:41:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Cb6gRitiz7xJPChGl6HRGs/hag1hhO3trM6Axq02QLg=; b=VYeF13Xo/F5mWIS/JKRnHEmfZiJrVLOkX73uzhzL9LdokFrgbVa1ry2t3o/XxaK7ug ppQvfhy1/eQkqDPVVUwJUKE1URzSN6Cfy9L6UADAzn0wwXE/897aJ18zAYvwu6Uh5dzD 3ZoorLwItLl42NMkFfcSLlaxKYN0KDdqtpG51s6/uhVGaaJsweYF65Afwbmc88mCvMYt L7rX0VpW09zg11OV8MjrlUqwkuJWp7I/7tEBJdyAtuCOPrvSQQe2ebNUQrM8LBQcOqlv lLBJcIE9rvbC40SrrR/eeRHsmC1u+KFl/x16mw/rAHMaQm9xlI85w4bwA/XyWRcc/eK7 TO3w== MIME-Version: 1.0 Received: by 10.182.162.66 with SMTP id xy2mr38593043obb.82.1357281702864; Thu, 03 Jan 2013 22:41:42 -0800 (PST) Received: by 10.76.139.232 with HTTP; Thu, 3 Jan 2013 22:41:42 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> Date: Fri, 4 Jan 2013 01:41:42 -0500 Message-ID: From: Jeff Wheeler To: "Saikat Ray (sairay)" , Tony Li Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk+6Tt1O31kNoUTwimmlj+J9JoX1INyVD2/2EosbnlzdCQZUGbD6NFV5R6hWfO5nlbth/Am Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 06:41:44 -0000 On Thu, Jan 3, 2013 at 9:53 PM, Saikat Ray (sairay) wrote: > [SR] Wrong in what sense? BGP code does not care whether it is a transit or an ASBR. What I described is exactly what the code will do. > (i) a path for a prefix (a "net") is withdrawn. > (ii) BGP deletes the path from that net. > (iii) BGP reruns bestpath computation. > (iv) If the bestpath changes, > (a) if there is a new bestpath, then BGP readvertises the new bestpath to all its peers > (b) if there is no bestpath (which would be the case when there is no path for the net), BGP will send withdraws to all its peers. Bugs can be present at other places than an ASBR. Imagine the following very ordinary network: AS100 --- [ ASBR2 --- AR3 --- ASBR4 --- ] AS500 ASBR2 will have iBGP routing exchange with ASBR4 by some means. This may be an ordinary iBGP session, via a route-reflector, or whatever. If AR3 is buggy but it is in the forwarding path between ASBR2 and ASBR4, then ASBR4 potentially will send packets to AR3, yet AR3 has treat-as-withdraw a route. ASBR4 is not subject to the bug, receives and installs the iBGP-learnt route from ASBR2, and happily announces it to AS500. Now you see that ASBR4 and AS500 can both send traffic into the network which is either blackholed or looped because of a bug in AR3. This is exactly why the base BGP specification has a lot of rules about what kind of routing policy you shouldn't apply to iBGP-learnt routes. You can create loops or blackholes with no malfunction at all, if your vendor has given you a little bit of rope -- the ability to apply a route-map to an iBGP neighbor and alter local-preference or various other path attributes which influence the bestpath decision. You certainly will encounter blackholes or loops if a router in the middle of your network is buggy and does treat-as-withdraw. If every AS contained only one router (or two), you would be correct. However, you have overlooked the possibility of a bug affecting just a path learnt by a transit router in the middle of an AS. On Thu, Jan 3, 2013 at 9:54 PM, Tony Li wrote: >> No, ignore-bad-message is not harder to implement. To say so is simply a lie. > > I'm sorry, but this conversation has taken a turn for the worse. I may be wrong (I really don't think so), but I am not lying. > > You owe me an apology and I'm not going to continue this conversation until you do. If calling your statement a lie has offended you, I apologize. It is, however, absolutely wrong; and you've framed it as absolutely right. To review, you've said that ignoring a BGP message is not even possible. Of course we know that isn't true. You've also said it is harder to ignore a message than to treat-as-withdraw. This is not true either. To do treat-as-withdraw you have to, at minimum, extract NLRI from a known to be damaged message. The current error-handling draft then requires you to apply numerous rules. Only then may you decide if you treat-as-withdraw or terminate the BGP session. Your assertions cannot possibly be correct in any implementation, period. The fact is you don't want to ignore messages. I am much more persuaded by your argument that ignoring messages may result in the persistence of bad RIB entries which may be re-forwarded within or outside the AS. That is a good argument. It's not constructive, however, to cloud the issue by making absurd statements like "ignoring a message is impossible." It is possible, you just feel strongly that it is the wrong approach. Operators continuously feel that the IETF does not understand their concerns. The IETF feels that operators don't participate. Both are right. I'm giving you the operator perspective and I am perfectly willing to admit that my suggestion is both extreme and potentially stupid; but I think it is still be smarter than the one on the table right now. It would be more productive for you to state the reason why you think ignoring messages is stupid, than to simply say it's not possible or it's too hard. If you want operators to participate in the process, you have got to be forthright with people who may have a very different view than you. I can say, I want to crush my thumb with a hammer, and you can tell me that's stupid and be right. If you say it's not possible because hammers don't work that way, of course I'm going to call you out because I know hammers can be swung in all manner of dangerous ways. If you tell me my position is stupid, at least that is a matter of opinion and open to argument. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From sairay@cisco.com Thu Jan 3 22:54:12 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719E121F8E64; Thu, 3 Jan 2013 22:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyBFqK4E+xFU; Thu, 3 Jan 2013 22:54:11 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AC77721F8E76; Thu, 3 Jan 2013 22:54:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=744; q=dns/txt; s=iport; t=1357282451; x=1358492051; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BxdHJP3wjNr6X5rr9ym9lkqftZMBQUBbrMXPISA7QGU=; b=IYfyQklL5kKiTEBJl9AnCUSPYKaQEYAwapJILOxQsb90T7ULE9QqFI70 zGrrckXikBL7D1sCuAb41DXdx5n1GqxiUy+vysg2HwlnsP7QS85dM91Yr FHgs8xjGxc2qToktIcjzfM0gV8J/OsnQGgP1dQYJrUnRYEOlHV2lxxUbr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMZ75lCtJXHB/2dsb2JhbABFvU8Wc4IfAQEEOj8QAgEIDhQUEDIlAgQBDQ2IC7ZlkDhhA6ZUgnSCJg X-IronPort-AV: E=Sophos;i="4.84,408,1355097600"; d="scan'208";a="155776746" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 04 Jan 2013 06:54:11 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r046sApG013898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 06:54:10 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.77]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 00:54:10 -0600 From: "Saikat Ray (sairay)" To: Jeff Wheeler , Tony Li Thread-Topic: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN6iX+pP5muDGR70G7eUwvXv72hJg4d8fggAClngD//5vq0A== Date: Fri, 4 Jan 2013 06:54:10 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A109942@xmb-rcd-x13.cisco.com> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.89.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 06:54:12 -0000 Bugs can be present at other places than an ASBR. Imagine the following ve= ry ordinary network: AS100 --- [ ASBR2 --- AR3 --- ASBR4 --- ] AS500 ASBR2 will have iBGP routing exchange with ASBR4 by some means. This may b= e an ordinary iBGP session, via a route-reflector, or whatever. If AR3 is buggy but it is in the forwarding path between ASBR2 and ASBR4, t= hen ASBR4 potentially will send packets to AR3, yet AR3 has treat-as-withdr= aw a route. ASBR4 is not subject to the bug, receives and installs the iBG= P-learnt route from ASBR2, and happily announces it to AS500. [SR] Ok. This however does not happen in bgp-free core (ASBR2 will tunnel=20 the packet to ASBR4 even if AR3 is in the forwarding path). From tony.li@tony.li Thu Jan 3 23:01:57 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD7721F86CD for ; Thu, 3 Jan 2013 23:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.21 X-Spam-Level: X-Spam-Status: No, score=-100.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT2d5uIPWoIT for ; Thu, 3 Jan 2013 23:01:56 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id E0FDC21F85EE for ; Thu, 3 Jan 2013 23:01:56 -0800 (PST) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta02.emeryville.ca.mail.comcast.net with comcast id jiwv1k0041eYJf8A2j1w9a; Fri, 04 Jan 2013 07:01:56 +0000 Received: from [192.168.2.103] ([98.248.36.188]) by omta19.emeryville.ca.mail.comcast.net with comcast id jj1t1k00J43ZcXW01j1uuW; Fri, 04 Jan 2013 07:01:56 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A109942@xmb-rcd-x13.cisco.com> Date: Thu, 3 Jan 2013 23:01:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <987CD2AD-61DA-46A3-83F3-F12483B4DD37@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A109942@xmb-rcd-x13.cisco.com> To: "Saikat Ray (sairay)" X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357282916; bh=xn2Gfa3YHMHE8bE8C8dM2gKO9jP6LE6yVcynsb5ASF0=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=nZJxOc6OSaSUzUD13V8JRXwpuNELWGMSvCaYaw/ysPCi87PEdegdqov8zDbUu3VQk QZstcuS4wZ/+Z+tYtxWldgkg83yEkR/Mv7NI0Z9RzRv2TSOcNcK7EXe+olL/7e6B4b zI01hI434doc3H7JD6E70gbnMZ+UUYDcul1tbC7mP6Zf/dzl7o3X/XoaZIaVL2PiU8 udCkoRR2D2HXoraK2tAel/yhkvFaaUSsYWWsh5wuDDQJxmGPGRdEjFl0KFVc9JRhuJ olFsooTIc7WxfcPxSnLlnrf2jos4lqtaihFu908HlKzBhd+H2rQuXawcabowc/AiHZ p33KwDSY6V2nw== Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 07:01:57 -0000 > Bugs can be present at other places than an ASBR. Imagine the = following very ordinary network: >=20 > AS100 --- [ ASBR2 --- AR3 --- ASBR4 --- ] AS500 >=20 > ASBR2 will have iBGP routing exchange with ASBR4 by some means. This = may be an ordinary iBGP session, via a route-reflector, or whatever. > If AR3 is buggy but it is in the forwarding path between ASBR2 and = ASBR4, then ASBR4 potentially will send packets to AR3, yet AR3 has = treat-as-withdraw a route. ASBR4 is not subject to the bug, receives = and installs the iBGP-learnt route from ASBR2, and happily announces it = to AS500. >=20 > [SR] Ok. This however does not happen in bgp-free core (ASBR2 will = tunnel=20 > the packet to ASBR4 even if AR3 is in the forwarding path). And we should also note that this can happen with ANY error recovery = mechanism. Anytime AR3 and ASBR4 receive different information or = process it differently, you'll have a problem. Also true with simple = session reset: if AR3 detects an error and shuts down its iBGP = connection, then ASBR4 won't know it and you've got a blackhole. Bottom line: this situation already occurs with session reset, will = occur with treat-as-withdraw, and will occur with ignore-bad-messages. So, what was the point of this argument again? Tony From tony.li@tony.li Thu Jan 3 23:15:49 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F8921F8E9F for ; Thu, 3 Jan 2013 23:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.21 X-Spam-Level: X-Spam-Status: No, score=-100.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf11zuDB5EAv for ; Thu, 3 Jan 2013 23:15:48 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 54B0121F8E9E for ; Thu, 3 Jan 2013 23:15:48 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta03.emeryville.ca.mail.comcast.net with comcast id jiWy1k0071ZMdJ4A3jFonf; Fri, 04 Jan 2013 07:15:48 +0000 Received: from [192.168.2.103] ([98.248.36.188]) by omta16.emeryville.ca.mail.comcast.net with comcast id jjFm1k00N43ZcXW8cjFm01; Fri, 04 Jan 2013 07:15:47 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Thu, 3 Jan 2013 23:15:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357283748; bh=GyFUidsC0zpR7vC298nPOmXXWx8G+9zXvmb7aMmBUxM=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=lCHncZM+5AzL+XOml9rrekewSxEezypfGm2cKRZ8GsWstm542tJD60XLhIwIkpjPi UxASwL8T9gzs5lCfPAh7Qmbq22JGKaxxz7rC7rKg0dhN+GJVwN3v23lDL5lwoaHr/f NHoVMqXtoprzUqTneRsEyglTFhFA6lWYHkHgtVbMB8hAK7SYyVjoKRjbTsPbE3Gp/j RDgm3J6eGTMM0Z5uHcWd+Z51pdzGoOWyqYSii64oDDszDlRD7G0ap7e+sxFUAuv5Ij MrdwVMfMIwmloMbH3SQQEMmE4xb4qFsHkui9FZqeTk4bOvxfp8oETbq0eSPt7CKJ7o 4IPCSX7za/rBA== Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 07:15:49 -0000 Jeff, >>> No, ignore-bad-message is not harder to implement. To say so is = simply a lie. >>=20 >> I'm sorry, but this conversation has taken a turn for the worse. I = may be wrong (I really don't think so), but I am not lying. >>=20 >> You owe me an apology and I'm not going to continue this conversation = until you do. >=20 > If calling your statement a lie has offended you, I apologize. =20 Thank you. > It is, > however, absolutely wrong; and you've framed it as absolutely right. You're welcome to disagree. It remains my opinion about the coding = complexity. I think my experience with BGP coding speaks for itself. = What's yours again? > To review, you've said that ignoring a BGP message is not even > possible. Of course we know that isn't true. =20 Do we? Given an arbitrary set of errors on a byte stream where there = are no guaranteed delimiters, how do you propose to resynchronize with = absolute certainty. My position is that it is risky as it requires = certain inferences. > You've also said it is > harder to ignore a message than to treat-as-withdraw. This is not > true either. So you can tell us what's true and what's not? I'm dying to know about O.J., L.H. Oswald, and Marilyn. Do tell. ;-) Yes, in my professional opinion, trying to recover from the semantic = errors is pretty straightforward. Recovering from the syntactic errors = is not going to work and will end up as a reset. Guessing about the = message delimiters is going to be messy and hard. > To do treat-as-withdraw you have to, at minimum, extract > NLRI from a known to be damaged message. The current error-handling > draft then requires you to apply numerous rules. Only then may you > decide if you treat-as-withdraw or terminate the BGP session. Your > assertions cannot possibly be correct in any implementation, period. Again, I was speaking to a practical implementation, not necessarily = what the draft is currently specifying. The reality is simple: extract = the NLRI. If you can do so cleanly, then treat them all as withdrawn = and syslog loudly. If you can't extract the NLRI cleanly, then it's = reset time. > The fact is you don't want to ignore messages. I am much more > persuaded by your argument that ignoring messages may result in the > persistence of bad RIB entries which may be re-forwarded within or > outside the AS. That is a good argument. It's not constructive, > however, to cloud the issue by making absurd statements like "ignoring > a message is impossible." It is possible, you just feel strongly that > it is the wrong approach. It is impossible to do so in the general case with 100% certainty. You = have lost context on the data stream. You can no longer distinguish = between data and TLV overhead. There is (unfortunately) no redundancy = that you can use to determine that any hypothetical recovery is correct. = That makes it a poor error recovery approach. Now, if we had thought to have put a CRC-16 at the end of each message, = we'd be in much better shape. Sigh. Tony From heas@shrubbery.net Thu Jan 3 23:59:43 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE03E21F8E92; Thu, 3 Jan 2013 23:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL6-x+xaN79v; Thu, 3 Jan 2013 23:59:43 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C64C21F86A5; Thu, 3 Jan 2013 23:59:43 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 2EF799A022; Fri, 4 Jan 2013 07:59:44 +0000 (UTC) Date: Fri, 4 Jan 2013 07:59:44 +0000 From: heasley To: Tony Li Message-ID: <20130104075944.GS86753@shrubbery.net> References: <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 07:59:44 -0000 Thu, Jan 03, 2013 at 02:31:16PM -0800, Tony Li: > As I've said before, errors can be reasonably classified into two groups: syntactic and semantic. > > A syntactic error would be any inconsistency of length fields, incompatibility between a type and a length, or any other error that would introduce any doubt about the parsing of the message. Once this type of error has occurred, then the remainder of the data stream is wholly in doubt. A session reset seems like the only (conservative) way of handling this, as it's unclear that further data would be accurate. Amen. if you've come upon a syntactic error and therefore have zero confidence that any bit in the message is correct, I dont understand how you could have any confidence that treat-as-withdraw is treating the right prefix(es) as withdrawn, or even logging the right prefix(es). you cant even have confidence about the length of the message. The aforementioned sesson re-establishment suppression seems a far better and consistent approach; it also doesnt seem to be the subject for an rfc. From jsw@inconcepts.biz Fri Jan 4 00:29:56 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC4821F8E11 for ; Fri, 4 Jan 2013 00:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awocgwl3rNJX for ; Fri, 4 Jan 2013 00:29:55 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0E39D21F8E08 for ; Fri, 4 Jan 2013 00:29:54 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id 17so19566371iea.30 for ; Fri, 04 Jan 2013 00:29:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=qGzGxfTTd+eZhuKZGgoiPfmS/Oayb1pH2OVc4alQ0aA=; b=fls42gkbMuxu04nvv9SanwF8mwZHYoo/7HigkTrFEyjTGYwEAHmv1PnBS6g3ZKX9Jk YbjWLln1fMatL8GHN0QU+3RP/cb8LW4LMx8fSp2Q6vi0yght3XJnok219JPW46ZzZhux uv8cVvljXwdGBGy06T0LMCSn5XA05fKuSyI6be7ARBxbr6K2OY1QWw8hJbIZ48/ts0h5 7XaUYEGbogyJYrbFC+iE/58ajl8xyXN2eXUPqGQaY/vCx7zJSa1b7zKC+0uGTMFCNuLh t6Q5+iSa4IFS7ClS9QpRWQo582JxsXYKBmp+F8lre5BL9AVVOY6M58u1RgxYJL3xBun2 RbKg== MIME-Version: 1.0 Received: by 10.50.88.136 with SMTP id bg8mr40143175igb.96.1357288194435; Fri, 04 Jan 2013 00:29:54 -0800 (PST) Received: by 10.64.132.33 with HTTP; Fri, 4 Jan 2013 00:29:54 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A109942@xmb-rcd-x13.cisco.com> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A109942@xmb-rcd-x13.cisco.com> Date: Fri, 4 Jan 2013 03:29:54 -0500 Message-ID: From: Jeff Wheeler To: "Saikat Ray (sairay)" , Tony Li Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkv3iqenuIb6j3opLpydpD7mGSRuqLUJUlq7nG7m3JaZHlNVaKZyvYNC5sdSzNMZaeEJhxV Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 08:29:56 -0000 On Fri, Jan 4, 2013 at 1:54 AM, Saikat Ray (sairay) wrot= e: > [SR] Ok. This however does not happen in bgp-free core (ASBR2 will tunnel > the packet to ASBR4 even if AR3 is in the forwarding path). Yes, absolutely true. On Fri, Jan 4, 2013 at 2:01 AM, Tony Li wrote: > And we should also note that this can happen with ANY error recovery mech= anism. Anytime AR3 and ASBR4 receive different information or process it d= ifferently, you'll have a problem. Also true with simple session reset: if= AR3 detects an error and shuts down its iBGP connection, then ASBR4 won't = know it and you've got a blackhole. > > Bottom line: this situation already occurs with session reset, will occur= with treat-as-withdraw, and will occur with ignore-bad-messages. > > So, what was the point of this argument again? The point is that treat-as-withdraw is relatively complicated and does not solve all the problems that many list participants might expect it to. Ignore-bad-message is less complicated. It has similar problems to treat-as-withdraw but the implementation cost, and bug risk, is lower. Because several posters have expressed concern about the complexity of additional code required to implement treat-as-withdraw, and because some aspects of it truly haven't been thought through yet, it is useful to compare treat-as-withdraw to something simple, even if it may seem stupid at first. On Fri, Jan 4, 2013 at 2:15 AM, Tony Li wrote: > You're welcome to disagree. It remains my opinion about the coding compl= exity. I think my experience with BGP coding speaks for itself. What's yo= urs again? For 13 years I've maintained a reference implementation of BGP for the purpose of troubleshooting vendor implementations. I'm posting, however, to speak from the operator perspective. There are plenty of programmers participating in the IETF process, and not enough operators. >> To review, you've said that ignoring a BGP message is not even >> possible. Of course we know that isn't true. > > Do we? Given an arbitrary set of errors on a byte stream where there are= no guaranteed delimiters, how do you propose to resynchronize with absolut= e certainty. My position is that it is risky as it requires certain infere= nces. If you read back a few posts, you'll note that I suggest it is possible (without certainty, though) to re-synchronize using the MARKER. I'm not saying you must do that. To ignore a Message you can just ignore all of its contents. If the Message Length is correct, then you do not need to re-synchronize, because the Message framing won't have been lost. I also suggested this in the same post. You've tied a need to re-sync the Message stream, to the simple ability to ignore Messages. You don't have to do both. If your argument is that re-sync is too hard to be worthwhile, I'll buy into your opinion; but you should still consider the simple case if ignoring Messages with no re-sync feature. All you need to do to just ignore Messages is ignore the content of a malformed message and move on. Either the Message Length will be correct and the following Message will begin with a MARKER, or it won't. What this buys you is much of what treat-as-withdraw intends to fix with almost no implementation cost. >> You've also said it is >> harder to ignore a message than to treat-as-withdraw. This is not >> true either. > > So you can tell us what's true and what's not? > > I'm dying to know about O.J., L.H. Oswald, and Marilyn. Do tell. ;-) I've written several times how to ignore messages easily. You already know how though, you just think it's a bad idea. This is a reasonable place to disagree. I'll save my opinion about JFK for another time. > Now, if we had thought to have put a CRC-16 at the end of each message, w= e'd be in much better shape. Sigh. Indeed. --=20 Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From rjs@rob.sh Fri Jan 4 00:52:31 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB4621F8E91; Fri, 4 Jan 2013 00:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n4mn8bVbTT3; Fri, 4 Jan 2013 00:52:31 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id D9C0E21F8E51; Fri, 4 Jan 2013 00:52:25 -0800 (PST) Received: from [46.65.174.227] (helo=latte.munster) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1Tr2xf-0006Lw-MT; Fri, 04 Jan 2013 08:49:07 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> Date: Fri, 4 Jan 2013 08:52:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4A571FEC-A4B9-49BF-B55B-C617B302F388@rob.sh> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.1283) Cc: idr@ietf.org, grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 08:52:31 -0000 On 3 Jan 2013, at 22:05, Jared Mauch wrote: > Oh, I understand all these use-cases, but there is a case for a = well-designed network not always sharing/mixing the NLRI. eg: We don't = transport v4 NLRI in v6 transport, nor v6 NLRI in v4 transport. If you = have a single session with massive shared fate, perhaps it's not a = protocol design error but a network design error. I would highlight that public Internet networks are NOT the only = implementation of BGP. Yes, in the Internet you can divide the two = topologies that you have (the v4 DFZ and the v6 DFZ) into separate = sessions to separate fate. However, a (I will assert, significant) = number of operators run networks which run one address family that has = numerous entirely separate topologies within it (e.g., L3VPN). There are = no mechanisms that provide separation between such routing topologies = within that AFI, SAFI, and it is not practical or scalable to divide = these into individual sessions per-topology. One of the taxes that we have with MP-BGP is that there are multiple = applications which may not all have exactly the same deployment = characteristics, or sensitivities. IMHO, we need to make sure we are = considering all applications of BGP when considering this subject (this = is one of the points that the draft that this thread relates to tries to = cover). Having said that, where there are means where failure domains = can be limited e.g. multi-session and/or separating AFI,SAFIs onto = different transport sessions, of course, these form part of the = solution. Cheers, r. From rraszuk@gmail.com Fri Jan 4 02:45:30 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE36C21F8ED9; Fri, 4 Jan 2013 02:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ug7FUbzHLLdw; Fri, 4 Jan 2013 02:45:26 -0800 (PST) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9665221F8ED7; Fri, 4 Jan 2013 02:45:26 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id s32so13704020iak.12 for ; Fri, 04 Jan 2013 02:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oUT0g0yEznUWNk5P9tQ/zlpBlfvg0RCkOhqE3pv58B4=; b=G4sl5S4QUG1Hhvy+JmQdpsTnfJUawBTpQsOX3pH0tnh0Y3Wrj3bU+1sHRpjSA6v4OL sTsxFvLnXMHLidmKVok1qWsXMOcy/3GSUgyVwYIXeLYfY4k7lnwT3A6cTfEduFYXAHSA sXnm+l16tI59PRXKApfMA62OaICSdsMfqXe1L9c3E65xzpAuRfSbBMf3XFd79xS0SEsH VBhCe3URlKPVLd9rYhHS6IO4YxDW9MeWh8PSVgy4Ewmue+a5dGatwygWG6p/cgcouLuo +BcPeXB0keksQAFclQW2hdHxDeMZmYNANe9o4EyKP0mGgfq9PKiSaJXgmvX3PV71gM1M DZNA== MIME-Version: 1.0 Received: by 10.50.94.134 with SMTP id dc6mr39482648igb.80.1357296326213; Fri, 04 Jan 2013 02:45:26 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.167.204 with HTTP; Fri, 4 Jan 2013 02:45:25 -0800 (PST) In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A109942@xmb-rcd-x13.cisco.com> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A109942@xmb-rcd-x13.cisco.com> Date: Fri, 4 Jan 2013 11:45:25 +0100 X-Google-Sender-Auth: 9uDSzeghrbMYBya_jiPoPUQaQ-k Message-ID: From: Robert Raszuk To: "Saikat Ray (sairay)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" , "grow@ietf.org" , Tony Li Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 10:45:31 -0000 Saikat, > [SR] Ok. This however does not happen in bgp-free core (ASBR2 will tunnel > the packet to ASBR4 even if AR3 is in the forwarding path). True but http://tools.ietf.org/html/draft-ietf-idr-error-handling-03 does not mandate nor recommend to use "treat-as-withdraw" in IBGP in tunneled only networks. Once you upgrade your router to new release it careless if there is MPLS or GRE running in your domain. In fact it says quite clearly: Although the "treat-as-withdraw" error-handling behavior defined in Section 2 makes every effort to preserve BGP's correctness, we note that if an UPDATE received on an IBGP session is subjected to this treatment, inconsistent routing within the affected Autonomous System may result. The consequences of inconsistent routing can include long-lived forwarding loops and black holes. Rgs, R. From stbryant@cisco.com Fri Jan 4 03:13:48 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3F421F8CF4 for ; Fri, 4 Jan 2013 03:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRhudN4uXv88 for ; Fri, 4 Jan 2013 03:13:47 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id D370921F8D4C for ; Fri, 4 Jan 2013 03:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5629; q=dns/txt; s=iport; t=1357298027; x=1358507627; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JhybqruFE+nR4i1UA6Bs1GLjEgDIhBcXs2vnEmITvO0=; b=GOFDQKfAGMTrALIvu9GL7+hWiOX4j44VXwXrRA6chN2a2uOrMvzxHjdr SwZY9nf9pp810RFVEr2eqPin84eNlEoi+n4cx3KHyD21mCBbpN0AiViIB DewE/w0oeHn1W20Jt0qRP4NZCN54KJ/vP2NLoBzQ8sgbjlvBZrs2a61vM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcIAMC45lCQ/khR/2dsb2JhbABFg0i6CBZzgh4BAQEEAQEBNTYKAQwECw4DBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAYgPDLVyjFaEQwOLU4o5hWtviW6CdA X-IronPort-AV: E=Sophos;i="4.84,409,1355097600"; d="scan'208";a="10867594" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 04 Jan 2013 11:13:45 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r04BDjIg009653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2013 11:13:45 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r04BDhOm002724; Fri, 4 Jan 2013 11:13:43 GMT Message-ID: <50E6B966.9060409@cisco.com> Date: Fri, 04 Jan 2013 11:13:42 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Susan Hares References: <20121129191043.GA9189@puck.nether.net> <50D328DC.2020906@umn.edu> <20121220152721.GA3551@puck.nether.net> <50D33972.8090302@umn.edu> <50D33D9D.3070400@foobar.org> <020a01cddefc$dd1e5590$975b00b0$@ndzh.com> <20121220223820.GA19458@puck.nether.net> <025801cddf05$22871100$67953300$@ndzh.com> <20121220230206.GA26708@puck.nether.net> <027501cddf08$8fecddd0$afc69970$@ndzh.com> In-Reply-To: <027501cddf08$8fecddd0$afc69970$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, 'Pete Resnick' Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 11:13:48 -0000 I think that it should be BCP, but there has been a lot of technical discussion on the IESG of late on exactly what is or is not allowed to be a BCP. However let's not get distracted by what goes in the top left corner let's focus on the content and get the required BGP behaviour. - Stewart On 20/12/2012 23:20, Susan Hares wrote: > Jon: > > Please refer to my comment on BCP as I believe it must be a BCP since it > modifies a BCP. In a BCP, I believe the MUST uses RFC 2119. > I believe, the WG chairs can change it to a BCP given it modifies a BCP - as > an editorial change. > > I've asked for Stewart Bryant to give us a read on the BCP issue. And as > always, the WG will speak if up someone objects. > > Sue > > -----Original Message----- > From: Jon Mitchell [mailto:jrmitche@puck.nether.net] > Sent: Thursday, December 20, 2012 6:02 PM > To: Susan Hares > Cc: 'Randy Bush'; 'Nick Hilliard'; idr@ietf.org; stbryant@cisco.com; Pete > Resnick > Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 > > > I agree with the understanding (in fact one might say this is implied > already by this being for Private Use). A question for you or Randy.. > does this make RFC 2119 a normative or informative reference given this is > not a standards track document? If Normative, should I include the > prescribed "Specification of Requirements" section text as well? > > On Thu, Dec 20, 2012 at 05:55:39PM -0500, Susan Hares wrote: >> Jon: >> >> My understanding of your text is that it operationally MUST be done. I >> like you, will leave the "how to" to implementations and operators. If >> it's a filters or pure fairy-magic, it is fine by me. I do not think >> this MUST modification implies the method. >> >> My understanding from my wonderful Routing ADs is something that >> modifies a BCP (RFC1930) is generally a BCP. However, we'll let >> Stewart Bryant (our Routing AD) weigh in on that fact. >> >> Sue >> >> >> -----Original Message----- >> From: Jon Mitchell [mailto:jrmitche@puck.nether.net] >> Sent: Thursday, December 20, 2012 5:38 PM >> To: Susan Hares >> Cc: 'Randy Bush'; 'Nick Hilliard'; idr@ietf.org; stbryant@cisco.com >> Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 >> >> >> I'm comfortable making the change to a capital MUST for this sentence >> and adding the appropriate reference to RFC 2119 as necessary. I'm >> just not comfortable telling operators how to perform that action as >> there are a number of options to do so, which was my point to David >> (and he seemed to be ok with). I will make the changes as necessary >> to the abstract where this statement exists as well. >> >> As for BCP versus info, I leave that up to the chairs, but this does >> not obsolete or otherwise change text in RFC 1930 outside of the IANA >> considerations section (RFC 1930 is primarily about justification for >> an ASN). There is no "practice" being advocated by the draft to be >> best or current, outside of the practice of not sending Private Use >> ASNs to the Internet. >> >> Jon >> >> On Thu, Dec 20, 2012 at 04:56:27PM -0500, Susan Hares wrote: >>> Randy and Nick: >>> >>> Please note that Randy is correct about the use of MUST language, >>> and it is an appropriate editorial question for WG LC or the period >>> between WG LC and IETF LC ending. >>> >>> For my clarification, why is the following text using "must" without >>> the MUST language? >>> >>> If Private Use ASNs are used and prefixes are originated from these >>> ASNs which are destined to the Internet, Private Use ASNs must be >>> removed from the AS_PATH before being advertised to the global >>> Internet. >>> >>> In my reading of this text, it is specifying the 2119 language. In >>> this case the text would be: >>> >>> If Private Use ASNs are used and prefixes are originated from these >>> ASNs which are destined to the Internet, Private Use ASNs MUST be >>> removed from the AS_PATH before being advertised to the global >>> Internet. >>> >>> I look forward to the authors comment on this point. Since this >>> document is modifying a BCP (RFC1930), it is likely to be a BCP. >>> Please >> note I consider >>> this an issue that the authors need to address this RFC2119 issue. >> Please >>> note this type of editorial review is normal during the post WG-LC >>> when the chairs perform an editing review prior writing up a IESG >> Shepherding report. >>> >>> >>> I am not widening our restricted request for advice on the WG LC >> agreement. >>> We are still focus this week on the range. >>> >>> May you have Shalom in your Holidays, >>> >>> Sue >>> >>> -----Original Message----- >>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf >>> Of Randy Bush >>> Sent: Thursday, December 20, 2012 12:04 PM >>> To: Nick Hilliard >>> Cc: idr@ietf.org >>> Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 >>> >>>> I don't think the IETF is too hot on the idea of "MUST" appearing >>>> in non normative documents? >>> normative is how a document is referred to by another document, and >>> one can never know that. >>> >>> and, despite common rumor, one can have 2119 language in an info or bcp. >>> >>> rand >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From john@jlc.net Fri Jan 4 03:47:25 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9F621F8ABA for ; Fri, 4 Jan 2013 03:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PddH0Nooa9J5 for ; Fri, 4 Jan 2013 03:47:25 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9B621F8A99 for ; Fri, 4 Jan 2013 03:47:25 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id EC72033C20; Fri, 4 Jan 2013 06:47:24 -0500 (EST) Date: Fri, 4 Jan 2013 06:47:24 -0500 From: John Leslie To: Randy Bush Message-ID: <20130104114724.GF25817@verdi> References: <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <20130104031414.GE25817@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: idr@ietf.org Subject: Re: [Idr] ACK/NAK (was ...reqs-for-bgp-error-handling) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 11:47:25 -0000 Randy Bush wrote: > > the first problem is that, as tli and others have said, bgp has no > framing, no tlv structure. so once parse has an error, all bets > are off. If parse fails so completely as to not find a next message, clearly NOTIFY is required. (I am willing to listen to Jeff's argument that 16 bytes of all-ones constitutes framing -- but I take no position on whether that's workable.) Note also that the _lack_ of an ACK could signal a lost message. > you need to 'solve' this before you know you have anything to ack. It certainly deserves to be solved in a BGP5; but there's a large class of errors where framing isn't the issue. -- John Leslie From john@jlc.net Fri Jan 4 03:53:43 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CD721F8CF4 for ; Fri, 4 Jan 2013 03:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inj5CGEefD5d for ; Fri, 4 Jan 2013 03:53:43 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6697321F8739 for ; Fri, 4 Jan 2013 03:53:43 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 31AFC33C2B; Fri, 4 Jan 2013 06:53:43 -0500 (EST) Date: Fri, 4 Jan 2013 06:53:43 -0500 From: John Leslie To: Jakob Heitz Message-ID: <20130104115343.GG25817@verdi> References: <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <20130104031414.GE25817@verdi> <2F3EBB88EC3A454AAB08915FBF0B8C7E14D1DF@eusaamb109.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14D1DF@eusaamb109.ericsson.se> User-Agent: Mutt/1.4.1i Cc: "idr@ietf.org" Subject: Re: [Idr] ACK/NAK (was ...reqs-for-bgp-error-handling) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 11:53:44 -0000 Jakob Heitz wrote: > > When does an router NAK or ACK? > After parsing? > after running policy? > after installation in the BGP loc-RIB? > after installing in the FIB? > after doing route selection? I don't think we need to settle that quite yet: we could even decide to have multiple flavors of ACK, some of them "incomplete". The point is that a NAK means the whole message has been ignored or backed out. > It is not just parsing errors that cause session resets. > We can not reliably know when to ACK to make sure all > bugs are covered. True. There will be bugs that require a NOTIFY regardless. But we could cover a lot of ground with ACK/NAK... -- John Leslie From randy@psg.com Fri Jan 4 04:00:19 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0B121F84DA for ; Fri, 4 Jan 2013 04:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8psqIwKGOXg for ; Fri, 4 Jan 2013 04:00:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9352B21F84D9 for ; Fri, 4 Jan 2013 04:00:19 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tr5wg-0006NN-0l; Fri, 04 Jan 2013 12:00:18 +0000 Date: Fri, 04 Jan 2013 21:00:17 +0900 Message-ID: From: Randy Bush To: John Leslie In-Reply-To: <20130104114724.GF25817@verdi> References: <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <20130104031414.GE25817@verdi> <20130104114724.GF25817@verdi> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr@ietf.org Subject: Re: [Idr] ACK/NAK (was ...reqs-for-bgp-error-handling) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 12:00:20 -0000 > If parse fails so completely as to not find a next message if parse fails, you do not know if you have found the next message, the typing of a million monkeys, or the output of a self-appointed bgp expert. randy From john@jlc.net Fri Jan 4 04:45:57 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD71121F88FB for ; Fri, 4 Jan 2013 04:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYmfl6ydeqxe for ; Fri, 4 Jan 2013 04:45:57 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCB621F88F7 for ; Fri, 4 Jan 2013 04:45:57 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0E21733D18; Fri, 4 Jan 2013 07:45:57 -0500 (EST) Date: Fri, 4 Jan 2013 07:45:57 -0500 From: John Leslie To: Randy Bush Message-ID: <20130104124557.GI25817@verdi> References: <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <20130104031414.GE25817@verdi> <20130104114724.GF25817@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: idr@ietf.org, John Leslie Subject: Re: [Idr] ACK/NAK (was ...reqs-for-bgp-error-handling) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 12:45:57 -0000 Randy Bush wrote: > > if parse fails, you do not know if you have found the next message, > the typing of a million monkeys, or the output of a self-appointed > bgp expert. But, of course, I didn't know that _before_ parse failed... It's the self-appointed BGP-expert you have to watch out for. ;^) -- John Leslie From jared@puck.nether.net Fri Jan 4 05:51:40 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B2F21F8930; Fri, 4 Jan 2013 05:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTfqoipC01Mo; Fri, 4 Jan 2013 05:51:39 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id AD1D621F892F; Fri, 4 Jan 2013 05:51:39 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id r04DpaQ0026656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Jan 2013 08:51:37 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Fri, 4 Jan 2013 08:51:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> To: Jeff Wheeler X-Mailer: Apple Mail (2.1283) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Fri, 04 Jan 2013 08:51:38 -0500 (EST) Cc: idr@ietf.org, grow@ietf.org, Tony Li Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 13:51:40 -0000 On Jan 3, 2013, at 9:33 PM, Jeff Wheeler wrote: >> Non-sequitur. Cyclic resets are orthogonal to treat-as-withdraw. As = enumerated above, ignore-bad-message is harder to implement and is more = dangerous. >=20 > No, ignore-bad-message is not harder to implement. To say so is = simply a lie. Jeff, The challenge I see here is that the NLRI is always at the END of the = message. The parsing problem is going to happen before the NLRI. I = certainly don't want my BGP implementation doing 'fuzzy' things with the = message and producing further poor results. It's no way to run a = network, and can be difficult to code. Once again I must assert that this is a problem best left to be fixed in = the individual implementations. We can certainly expect a high level of = standard for software, but expecting no defects is unrealistic. - Jared= From tony.li@tony.li Fri Jan 4 09:43:02 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D1521F8864 for ; Fri, 4 Jan 2013 09:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.623 X-Spam-Level: X-Spam-Status: No, score=-97.623 tagged_above=-999 required=5 tests=[AWL=-2.413, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_SUMOF=5, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaJaHnkKoxRI for ; Fri, 4 Jan 2013 09:43:02 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 3820A21F8855 for ; Fri, 4 Jan 2013 09:43:02 -0800 (PST) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta02.emeryville.ca.mail.comcast.net with comcast id jrdQ1k0031bwxycA2tj2YS; Fri, 04 Jan 2013 17:43:02 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta18.emeryville.ca.mail.comcast.net with comcast id jtgl1k00o52qHCY8etgoQA; Fri, 04 Jan 2013 17:40:59 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Fri, 4 Jan 2013 09:02:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <23798B91-D652-4A61-9BF2-83F617C78F84@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A109942@xmb-rcd-x13.cisco.com> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357321382; bh=B/y1XL36d6gmyIg3fDnXVUMw3VnqUkfk0gjJk3Ce+ME=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=AAI4JfsemPDjGzN/I/Dmzy41HoArQS+VOwosq2GbILnUj/ziRccmiQQEYcwVine/w 4dPOhWopCCjuENGJUEO+x7DWO8NkQihQtAxeGu0vkAnk01FySHEExZuTMm64IO1tyf 6jzk33KDvdqsw7/v2mGZk2rACFQEXloz1K5+8FocsAk88XQXc/v760EicwZFvmASAI Qm97pVeEcP7jM7acS06rJrwX7x31EPs0GaATttUQNTJja5LtS/4nmwPuGuH9eoMGTV ctoZ2aPHrY4aP2QJ40cTakRgwRcL15bJVsSmGOgE6WUTxSRQ51WrWrMh/JwZbp/t2V Pc8MkkQrU4UpQ== Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 17:43:03 -0000 Jeff, >>> To review, you've said that ignoring a BGP message is not even >>> possible. Of course we know that isn't true. >>=20 >> Do we? Given an arbitrary set of errors on a byte stream where there = are no guaranteed delimiters, how do you propose to resynchronize with = absolute certainty. My position is that it is risky as it requires = certain inferences. >=20 > If you read back a few posts, you'll note that I suggest it is > possible (without certainty, though) to re-synchronize using the > MARKER. >=20 > I'm not saying you must do that. To ignore a Message you can just > ignore all of its contents. If the Message Length is correct, then > you do not need to re-synchronize, because the Message framing won't > have been lost. I also suggested this in the same post. True, but again, we're trying to deal with error handling. When the = interesting syntactic errors occur, then the Message Length is very much = in doubt. A typical syntactic error is an off-by-one inconsistency = between the Message Length and the sum of all of the lengths of the TLVs = (and overhead). There is no good reason to believe the Message Length = or the lengths of the TLVs is correct, so our code should probably check = both. Then check to see if the Marker (no need to shout ;-) is in the = right place. That's reasonable for off-by-one, but that's not the only possible = mistake. It's easy to have an inconsistency which is in the tens or = hundreds of bytes. Now what? We could again check both alternatives, = but again, the presence of a Marker, even in one of the possible = locations, is no guarantee. You could easily skip over an entire = message, for example, and end up ignoring two updates, not just one. > You've tied a need to re-sync the Message stream, to the simple > ability to ignore Messages. You don't have to do both. If your > argument is that re-sync is too hard to be worthwhile, I'll buy into > your opinion; but you should still consider the simple case if > ignoring Messages with no re-sync feature. As I've argued above, yes, I'd say that the re-sync risk vs. effort vs. = return tradeoff isn't worthwhile. I'm not sure why we would discuss a different error recovery mechanism = that doesn't deal with the syntactic errors. Again, if there are no = syntactic errors, then recovery by ignoring the message leaves the = network in an inconsistent state, as you've stipulated. Clearly, = treat-as-withdraw is preferable for this case. The remaining question = is how to deal with the syntactic errors. I've argued that we shouldn't = mess around and should just accept the session reset. > All you need to do to just ignore Messages is ignore the content of a > malformed message and move on. Either the Message Length will be > correct and the following Message will begin with a MARKER, or it > won't. What this buys you is much of what treat-as-withdraw intends > to fix with almost no implementation cost. I agree that the Message Length will either be correct or it won't. = Now, all us need is an oracle (the computer science kind ;-), to tell us = which is which. Got any handy? ;-) Regards, Tony From Donald.Smith@CenturyLink.com Fri Jan 4 09:54:30 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A4D21F889D; Fri, 4 Jan 2013 09:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJF9pELBQTBT; Fri, 4 Jan 2013 09:54:29 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5076E21F858A; Fri, 4 Jan 2013 09:54:29 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r04HsRER005195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jan 2013 11:54:28 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A7DFF1E0053; Fri, 4 Jan 2013 11:54:22 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 8764C1E0073; Fri, 4 Jan 2013 11:54:22 -0600 (CST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r04HsMFs010921; Fri, 4 Jan 2013 11:54:22 -0600 (CST) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r04HsLXh010900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 11:54:21 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0318.001; Fri, 4 Jan 2013 10:54:20 -0700 From: "Smith, Donald" To: "'Tony Li'" Thread-Topic: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN6ghxXiZLU84V50OUaJbShrXQr5g5aGnw Date: Fri, 4 Jan 2013 17:54:20 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A29F4B1@PDDCWMBXEX503.ctl.intranet> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <68EFACB32CF4464298EA2779B058889D0A29EF86@PDDCWMBXEX503.ctl.intranet> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'idr@ietf.org'" , "'grow@ietf.org'" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 17:54:30 -0000 "Pampers use multiple layers of protection to prevent leakage. Rommel used = defense in depth to defend European fortresses." (A.White) Donald.Smith@Cen= turyLink.com >-----Original Message----- >From: Tony Li [mailto:tony.li@tony.li] >Sent: Thursday, January 03, 2013 4:15 PM >To: Smith, Donald >Cc: 'Jeff Wheeler'; 'idr@ietf.org'; 'grow@ietf.org' >Subject: Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- >error-handling-06.txt > > >Hi Donald, > >>> A session reset seems like the only (conservative) way >>> of handling this, as it's unclear that further data would be >accurate. >> I disagree. Does a session reset fix the issue? It hasn't the last few >times I have seen this. >> It exasperated it by causing peers to drop and having to rebuild >ribs/fibs etc... continuously. > > >Which is why I suggested that re-opening the connection is perhaps not >optimal. Agreed. > > >> Other than getting it noticed I doubt a reset will ever make a >misbehaving router stop misbehaving. > > >The point is that once you've lost context in the data stream, >subsequent messages cannot be accepted with a reasonable certainty of >correct parsing. > > Understood on over runs or under runs (length errors). I am not sure that i= s true for ALL other issues. Such as the recent issue where the attribute had non-zero bits in the lower= nibble. >>> I'm very open to a discussion of alternatives to session flap for >these >>> cases. Should we require manual intervention before session restart? >> Manual intervention will be required in most cases but if we "require" >manual intervention haven't we left the programming side (state machine) >and gone into the operational control side of things? > > >Correct. The programming side has failed. As you note, trying again is >not likely to help. Adding Artificial Intelligence to BGP to recover is >unlikely to be effective or an efficient means of making progress. > > >>> Semantic errors would be consistency violations within the contents >of >>> the message. In these cases, treat-as-withdraw seems reasonable. >> I would also like the ignore option here. You know your neighbor is >saying something you don't understand, possibly due to a lack of in your >vocabulary but you understand other elements so you nod and continue >listening to the rest:) > > >The entire problem with the ignore option is that it leaves bogus >information in the network. Suppose that the update contains an AS path >change for a prefix. If you ignore the update, then you ignore that >path change, AND, you fail to propagate that change to your upstream >neighbors. Now, BGP's loop prevention mechanism is out the window and, >in the worst case, you've created an inter-domain forwarding loop. Agreed I now have bad data (incorrect or incomplete) from one peer but ever= ything else is still working. I haven't flapped the session. Now I have to talk to that peer (assuming th= is is noticed via syslog or snmp or something). Or that peer calls us and s= ays "why aren't you propagating this announcement" and we begin joint AS tr= oubleshooting. That is probably the best solution:) > >If, on the other hand, you withdraw that prefix, then any alternate >connectivity for that prefix can come into play. That makes sense and in big ISPs there will nearly always be another path. > >In short, treat-as-withdraw is a fail safe approach. Ignoring updates >is not. But in a peering world you have potentially just withdrawn all of your rout= es to a peer from that peer. You will now prefer some other peer for all of that peers traffic (or anoth= er connection to that peer in another location). If you can ignore a single update error from a peer while you troubleshoot = the issue with that peer it would allow a better path for the rest of that = peers announcements. Again anything with a overrun or under run issue sort = of implies the rest of the updates from that point forward are corrupted/un= trustworthy. Can you detect overrun and under runs without FPs or FNs? Probably not in a= ll cases. > >Tony From tony.li@tony.li Fri Jan 4 10:04:59 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1133121F88A1 for ; Fri, 4 Jan 2013 10:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.86 X-Spam-Level: X-Spam-Status: No, score=-99.86 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olkLA0BQb5OP for ; Fri, 4 Jan 2013 10:04:58 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 19BB221F8587 for ; Fri, 4 Jan 2013 10:04:58 -0800 (PST) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta03.emeryville.ca.mail.comcast.net with comcast id jpAG1k00A17UAYkA3u4yGS; Fri, 04 Jan 2013 18:04:58 +0000 Received: from [10.155.35.198] ([128.107.239.233]) by omta13.emeryville.ca.mail.comcast.net with comcast id ju2j1k00R52qHCY8Zu2lNa; Fri, 04 Jan 2013 18:02:56 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: <68EFACB32CF4464298EA2779B058889D0A29F4B1@PDDCWMBXEX503.ctl.intranet> Date: Fri, 4 Jan 2013 10:02:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <531D282B-9B6E-4D38-8D32-64011DF9854F@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <68EFACB32CF4464298EA2779B058889D0A29EF86@PDDCWMBXEX503.ctl.intranet> <68EFACB32CF4464298EA2779B058889D0A29F4B1@ PDDCWMBXEX503.ctl.intranet> To: "Smith, Donald" X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357322698; bh=vLb1hMiMym4ONB8M1x/DsZYxjafD2qzn4Lz/32Kg6qs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=M7fWsljtiS8uATRdBWd6YkT0Bdzv4lmLcGZVT1uHXp7ql5ZtS3IG/Ms2U6VFFBrC8 OBsL/QsbXQsdiMYz/ndvaKBBNtmVZbIG9l0pWPWSdLrJU6nl7sgSrBEYEBgZXIRcOr TFM6eOyfPHDiPbw08Ht6Y19LzxrwBYlAZSvo5YRY20hIdIPWi2D19iPwLxfNvpcNKY hlrSTV8LEGtztdC/K/9sCKNrAQozmRu1E0sxqi/+xGK/gockhk6Q8615yTnET2Klef N3KFifPyl3yL5oFlBPqFsmFuUBIpsScmcJOpQ3xptWhMeWDtQ4OkcoMyHqQRFBYady WEtI6/nsx3N7w== Cc: "'idr@ietf.org'" , "'grow@ietf.org'" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 18:04:59 -0000 On Jan 4, 2013, at 9:54 AM, "Smith, Donald" = wrote: >> In short, treat-as-withdraw is a fail safe approach. Ignoring = updates >> is not. > But in a peering world you have potentially just withdrawn all of your = routes to a peer from that peer. >=20 > You will now prefer some other peer for all of that peers traffic (or = another connection to that peer in another location). >=20 > If you can ignore a single update error from a peer while you = troubleshoot the issue with that peer it would allow a better path for = the rest of that peers announcements. Again anything with a overrun or = under run issue sort of implies the rest of the updates from that point = forward are corrupted/untrustworthy. > Can you detect overrun and under runs without FPs or FNs? Probably not = in all cases. >=20 Donald, As I would implement treat-as-withdraw, the scope of the withdrawal = would ONLY be for the message in question, and again it would only apply = to semantic errors where the NLRI could be cleanly extracted. So only = the prefixes in error would be affected, not necessarily everything from = that peer. =20 Detecting overrun and under run is not too hard. Again, the most common = cases are when the Message Length and TLV lengths are inconsistent. The = presence of the marker for the next message and a sane length field for = the next message are also helpful checks for detection. Again, some kind of redundancy for framing would have been a better = long-term design. I'll note that if folks are sufficiently motivated, = this COULD be retro-fit. Add an attribute that is a CRC-16 of the = entire message. Tony From jakob.heitz@ericsson.com Fri Jan 4 10:27:58 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DBA21F8947; Fri, 4 Jan 2013 10:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSawY5hQox9C; Fri, 4 Jan 2013 10:27:58 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAB021F8911; Fri, 4 Jan 2013 10:27:57 -0800 (PST) Received: from EUSAAHC005.ericsson.se ([147.117.188.87]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r04Ifr5W025196; Fri, 4 Jan 2013 12:41:55 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 13:27:49 -0500 From: Jakob Heitz To: Tony Li , Jeff Wheeler Thread-Topic: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN6qMAIoORt/SJvkGUT2B4yn6gmZg5etwQ Date: Fri, 4 Jan 2013 18:27:49 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14DB1E@eusaamb109.ericsson.se> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A109942@xmb-rcd-x13.cisco.com> <23798B91-D652-4A61-9BF2-83F617C78F84@tony.li> In-Reply-To: <23798B91-D652-4A61-9BF2-83F617C78F84@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 18:27:59 -0000 On , Tony Li <> wrote: > possible mistake. It's easy to have an inconsistency which > is in the tens or hundreds of bytes. Now what? We could > again check both alternatives, but again, the presence of a > Marker, even in one of the possible locations, is no > guarantee. You could easily skip over an entire message, for > example, and end up ignoring two updates, not just one. Or waiting for a very long time for that marker to arrive. Suppose the length is 40. You think it's 4000. You will sit there patiently for an eternity waiting for more bytes to arrive so you can read your next marker. I support http://tools.ietf.org/html/draft-ietf-idr-error-handling-03 with the understanding that it's the best we can do in a tricky situation to limit the damage. Damage will occur, but this limits it as best we can. --=20 Jakob Heitz. From jsw@inconcepts.biz Fri Jan 4 11:50:56 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081F121F890E for ; Fri, 4 Jan 2013 11:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3yRZjinTdLu for ; Fri, 4 Jan 2013 11:50:51 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 146D321F88EA for ; Fri, 4 Jan 2013 11:50:51 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id k10so20607835iea.29 for ; Fri, 04 Jan 2013 11:50:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=OGefrLs2FtRMdAIny96SQs1tDn2eKQzf7uCK8qT/rAk=; b=d/zZEwWvUzoM/HEcmWhrX0KxQTZnQzohgTf566eMZw2x+AI/NRfrPsqFIg4jkyjUmi 0/lYRkghFNEw1DgNklBFo/bTiu5BhGwUF7hUkBvnemd9zszRgU/REmLRp/yCjVt/HgYH u/Q4odMzGa7o0SHxBkFbDHAJ7dlAWg0NLF+BPpO/OcPGnaPdrQlGNr/8kj61r7mBDGrb ksVV4l2OOtckCspADkMDWtdXD3EcayIacaasWJnVctteLvu6y0SobD4j6H2ZIOL03d7J VltwO4Vny1eUmDSRxet/0M9hB4O42SjeX0ylwqtet7La7HdrrH9OQhKTdsck0NyCKo2v NO/Q== MIME-Version: 1.0 Received: by 10.42.180.65 with SMTP id bt1mr40253887icb.41.1357329050662; Fri, 04 Jan 2013 11:50:50 -0800 (PST) Received: by 10.64.132.33 with HTTP; Fri, 4 Jan 2013 11:50:50 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <23798B91-D652-4A61-9BF2-83F617C78F84@tony.li> References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <72CF9D03-9A2A-46D6-B65B-10849204879C@puck.nether.net> <54358BA2-AEE3-4AE5-9F5F-917CC0A17D70@puck.nether.net> <92C046A2-560E-47EA-AED5-B04EB333CF84@tony.li> <8ED5B0B0F5B4854A912480C1521F973A109800@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A10983B@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A109942@xmb-rcd-x13.cisco.com> <23798B91-D652-4A61-9BF2-83F617C78F84@tony.li> Date: Fri, 4 Jan 2013 14:50:50 -0500 Message-ID: From: Jeff Wheeler To: Tony Li , Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkQvi8iXwOm/Z5z5QUu2w1Gt6UPCEodu/rF/g/kr+y5cIYj5ETN87DEYY+V37cWWIJFyQEX Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 19:50:56 -0000 Almost no one has commented on whether or not a capability code should be used to re-order the contents of BGP Messages, and Attributes, as suggested by error-handling. This is really important if error-handling is to rely on such re-ordering. Many folks are saying error-handling needs it, the draft says it, yet no mechanism is proposed to do it? The closest thing is a recommendation in RFC4760bis but it is the opposite of what RFC4271 recommends. You can't actually know if your neighbor plans to follow this new recommendation because there's no way to signal that intent. In short, I suggest RFC4760bis should add a second capability that indicates the BGP speaker promises to send the MP attributes before all other attributes, as it recommends. I further suggest any re-ordering of native NLRI information in the Message needs to be addressed .. somewhere. On Fri, Jan 4, 2013 at 12:02 PM, Tony Li wrote: > That's reasonable for off-by-one, but that's not the only possible mistak= e. It's easy to have an inconsistency which is in the tens or hundreds of = bytes. Now what? We could again check both alternatives, but again, the p= resence of a Marker, even in one of the possible locations, is no guarantee= . You could easily skip over an entire message, for example, and end up ig= noring two updates, not just one. I'm glad you raise this possibility. Indeed, if you tried to re-sync the message stream by searching for a MARKER, you might skip many messages without realizing it. The potential damage to the RIB is high, so it is a high price to pay to avoid session-reset. > I agree that the Message Length will either be correct or it won't. Now,= all us need is an oracle (the computer science kind ;-), to tell us which = is which. Got any handy? ;-) As you know, when more data arrives from the neighbor, you can make a good guess based on the marker. I don't think divine intervention is necessary. On Fri, Jan 4, 2013 at 1:27 PM, Jakob Heitz wrot= e: > Or waiting for a very long time for that marker to arrive. > Suppose the length is 40. You think it's 4000. You will sit > there patiently for an eternity waiting for more bytes to > arrive so you can read your next marker. Sure, but this is not different than many other cases where the neighbor fails and you sit there waiting for HoldTime to expire. --=20 Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From chris.hall@highwayman.com Fri Jan 4 15:44:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E84721F8A6F; Fri, 4 Jan 2013 15:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv7YNBPmjI2S; Fri, 4 Jan 2013 15:44:17 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta005.mxout.tbr.inty.net [91.221.168.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAAF21F8A69; Fri, 4 Jan 2013 15:44:17 -0800 (PST) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id DB69AA6434A; Fri, 4 Jan 2013 23:44:15 +0000 (GMT) Received: from mdfmta005.tbr.inty.net (unknown [127.0.0.1]) by mdfmta005.tbr.inty.net (Postfix) with ESMTP id B6171A64340; Fri, 4 Jan 2013 23:44:15 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta005.tbr.inty.net (Postfix) with ESMTP; Fri, 4 Jan 2013 23:44:15 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TrGvu-00013M-RW; Fri, 04 Jan 2013 23:44:14 +0000 From: "Chris Hall" To: , Date: Fri, 4 Jan 2013 23:44:09 -0000 Organization: Highwayman Message-ID: <059d01cdead5$676701f0$363505d0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3q1WF/iDYQH8sbSQq326HmotM7Ug== Content-Language: en-gb X-MDF-HostID: 8 Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 23:44:18 -0000 Tony Li wrote (on Fri 04-Jan-2013 at 17:02 +0000): > To: Jeff Wheeler .... > I agree that the Message Length will either be correct or it won't. > Now, all us need is an oracle (the computer science kind ;-), to > tell us which is which. Got any handy? ;-) The outermost framing for the message is the Marker (16 x 0xFF) followed by two octets of Message Length and one of Type. Message Length must be > 19 <= 4096 (currently), and >= 23 for an UPDATE message. So, there are some constraints there. The next level of framing is the Withdrawn Routes Length and the Total Path Attributes Length. And 23 + those must equal the Message Length. That (as per the drafts) is about it, oracle-wise. A CRC would be nice -- but not amongst the Attributes, except, perhaps between the MP_XXX at the front of the Attributes and the rest. But long runs of 0xFF are pretty rare in the body of a message, so the Marker is not bad. When we start considering what buggy software might be capable of throwing out, I think we are in danger of running, Wile-E.-Coyote-wise, out into mid-air... Most code is tested before release. Some parts of the code are in constant use. I think it is practical to consider some things dependable. (Never 100% guaranteed, but many-sigma.) The outermost framing for a BGP Message is common to all messages. The code which writes the Message Length can be written so that the value is very closely tied to the value used to dispatch the message to the output buffers. This stuff is pretty well exercised, and I think that a systematic error here is unlikely. I can imagine some memory management, or multi-threading, or random corruption, or other exotic bug which could affect this outermost framing. And such a bug could lie dormant for a long time. These sorts of issues are notoriously capricious and hard to reproduce. Which is a Bad Thing but also a Good Thing, because following a session reset the bug may never be seen again ! The inner framing of Withdrawn Routes, Path Attribute and NLRI is also code in constant use. Given a discrepancy between the lengths of these and the Message Length, if pushed I would go with the Message Length. But, I would prefer to treat such a discrepancy as a session-reset. Mostly because I think that the balance of probabilities is that an error here is more likely to be a symptom of some exotic error than anything else. [Plenty of hostages to fortune there... I look forward to hearing of counter examples :-)] This is all per the drafts. When it comes down to it, the most likely place for systematic errors to occur is in obscure corners of attribute handling. eg the well-known RIPE/DUKE "experiment". I think that concentrating on those would be the most productive. There are enough issues to resolve there to keep one busy. It occurs to me: one issue with treating the Marker etc. as the one true message boundary, is that if the code finds itself reading forwards, looking for the next start of message, that implies that the Message Length on the _previous_ one was probably wrong... but all decisions relating to that previous message have already been made :-( That's not a problem if you reset the session. In extremis I guess one has bigger issues to worry about ! An option to resync on Marker etc, as a last-ditch, keep-the-session-up-at-all-costs measure, doesn't seem that difficult to me -- and wouldn't (key consideration) interfere with code for normal running. Chris From jakob.heitz@ericsson.com Fri Jan 4 16:00:33 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6721F8A8E; Fri, 4 Jan 2013 16:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, GUARANTEED_100_PERCENT=0.012, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e0wClLu9HAX; Fri, 4 Jan 2013 16:00:32 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CB19421F846E; Fri, 4 Jan 2013 16:00:32 -0800 (PST) Received: from EUSAAHC001.ericsson.se ([147.117.188.75]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r050EU8f009828; Fri, 4 Jan 2013 18:14:31 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 19:00:24 -0500 From: Jakob Heitz To: Chris Hall , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: Ac3q1WF/t97q/gmUgEurMinxhJgROQAAU9CA Date: Sat, 5 Jan 2013 00:00:23 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14E005@eusaamb109.ericsson.se> References: <059d01cdead5$676701f0$363505d0$@highwayman.com> In-Reply-To: <059d01cdead5$676701f0$363505d0$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 00:00:34 -0000 Current usages of BGP probably will not have anything matching a marker in the byte stream other than the marker. But future additions could well do that. There is a draft to increase the maximum length, so you can't rely on that being <=3D 4096. What about a notification message or a possible future operational message that replays the errant update. That will look just like an update to the resync code. On , Chris Hall <> wrote: > Tony Li wrote (on Fri 04-Jan-2013 at 17:02 +0000): >> To: Jeff Wheeler > .... >> I agree that the Message Length will either be correct or it won't. >> Now, all us need is an oracle (the computer science kind ;-), to >> tell us which is which. Got any handy? ;-) >=20 > The outermost framing for the message is the Marker (16 x 0xFF) > followed by two octets of Message Length and one of Type. Message > Length must be > 19 <=3D 4096 (currently), and >=3D 23 for an UPDATE > message. So, there are some constraints there. >=20 > The next level of framing is the Withdrawn Routes Length and the Total > Path Attributes Length. And 23 + those must equal the Message Length. >=20 > That (as per the drafts) is about it, oracle-wise. A CRC would be > nice -- but not amongst the Attributes, except, perhaps between the > MP_XXX at the front of the Attributes and the rest. But long runs of > 0xFF are pretty rare in the body of a message, so the Marker is not > bad.=20 >=20 > When we start considering what buggy software might be capable of > throwing out, I think we are in danger of running, > Wile-E.-Coyote-wise, out into mid-air... >=20 > Most code is tested before release. Some parts of the code are in > constant use. I think it is practical to consider some things > dependable. (Never 100% guaranteed, but many-sigma.) >=20 > The outermost framing for a BGP Message is common to all messages. > The code which writes the Message Length can be written so that the > value is very closely tied to the value used to dispatch the message > to the output buffers. This stuff is pretty well exercised, and I > think that a systematic error here is unlikely. I can imagine some > memory management, or multi-threading, or random corruption, or other > exotic bug which could affect this outermost framing. And such a bug > could lie dormant for a long time. These sorts of issues are > notoriously capricious and hard to reproduce. Which is a Bad Thing > but also a Good Thing, because following a session reset the bug may > never be seen again !=20 >=20 > The inner framing of Withdrawn Routes, Path Attribute and NLRI is also > code in constant use. Given a discrepancy between the lengths of > these and the Message Length, if pushed I would go with the Message > Length. But, I would prefer to treat such a discrepancy as a > session-reset. Mostly because I think that the balance of > probabilities is that an error here is more likely to be a symptom of > some exotic error than anything else. >=20 > [Plenty of hostages to fortune there... I look forward to hearing of > counter examples :-)]=20 >=20 > This is all per the drafts. >=20 > When it comes down to it, the most likely place for systematic errors > to occur is in obscure corners of attribute handling. eg the > well-known RIPE/DUKE "experiment". I think that concentrating on > those would be the most productive. There are enough issues to > resolve there to keep one busy. >=20 > It occurs to me: one issue with treating the Marker etc. as the one > true message boundary, is that if the code finds itself reading > forwards, looking for the next start of message, that implies that the > Message Length on the _previous_ one was probably wrong... but all > decisions relating to that previous message have already been made :-( > That's not a problem if you reset the session. In extremis I guess > one has bigger issues to worry about ! >=20 > An option to resync on Marker etc, as a last-ditch, > keep-the-session-up-at-all-costs measure, doesn't seem that difficult > to me -- and wouldn't (key consideration) interfere with code for > normal running.=20 >=20 > Chris --=20 Jakob Heitz. From john@jlc.net Fri Jan 4 16:34:33 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679CC21F8A9B; Fri, 4 Jan 2013 16:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE9ZI6SlEK2l; Fri, 4 Jan 2013 16:34:32 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3429B21F8B13; Fri, 4 Jan 2013 16:34:32 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 499B233D29; Fri, 4 Jan 2013 19:34:32 -0500 (EST) Date: Fri, 4 Jan 2013 19:34:32 -0500 From: John Leslie To: Jakob Heitz Message-ID: <20130105003432.GJ25817@verdi> References: <059d01cdead5$676701f0$363505d0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14E005@eusaamb109.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14E005@eusaamb109.ericsson.se> User-Agent: Mutt/1.4.1i Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 00:34:33 -0000 Jakob Heitz wrote: > > Current usages of BGP probably will not have anything matching > a marker in the byte stream other than the marker. I can't think of any way for it to get there that isn't an error... > But future additions could well do that. Sounds like a very bad idea to me. > There is a draft to increase the maximum length, > so you can't rely on that being <= 4096. Indeed: it will probably grow past 4096 sometime. > What about a notification message or a possible future > operational message that replays the errant update. Definitely a bad idea! Replay of an errant update can't help, and would likely crash its receiver. Don't do that! > That will look just like an update to the resync code. I'm not saying resync is necessarily a good thing -- but I believe a marker (16 bytes all ones) in the middle of _any_ message deserves an error of some kind. Lacking a TLV structure for messages, we should not let go of a marker which separates messages. -- John Leslie From jakob.heitz@ericsson.com Fri Jan 4 16:49:38 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE82C21F850C; Fri, 4 Jan 2013 16:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YciEsAX+V-LT; Fri, 4 Jan 2013 16:49:38 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 571EF21F8506; Fri, 4 Jan 2013 16:49:38 -0800 (PST) Received: from EUSAAHC007.ericsson.se ([147.117.188.93]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r0513WMc012460; Fri, 4 Jan 2013 19:03:38 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 19:49:35 -0500 From: Jakob Heitz To: John Leslie Thread-Topic: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN6txy2tR5Cg4rSE6gxRq5GR1+ZJg55kBw Date: Sat, 5 Jan 2013 00:49:33 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14E0BC@eusaamb109.ericsson.se> References: <059d01cdead5$676701f0$363505d0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14E005@eusaamb109.ericsson.se> <20130105003432.GJ25817@verdi> In-Reply-To: <20130105003432.GJ25817@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 00:49:38 -0000 On Friday, January 04, 2013 4:35 PM, John Leslie wrot= e: >> What about a notification message or a possible future >> operational message that replays the errant update. >=20 > Definitely a bad idea! >=20 > Replay of an errant update can't help, and would likely crash its > receiver. Don't do that!=20 Sorry, that's not what I meant. I meant a future operational message that says "this update message caused me a problem and here is the update message for your reference". It is a copy of the message, not actually a replay. --=20 Jakob Heitz. From jsw@inconcepts.biz Fri Jan 4 21:29:58 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3377721F880E for ; Fri, 4 Jan 2013 21:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXmSW8UYPPN6 for ; Fri, 4 Jan 2013 21:29:56 -0800 (PST) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id B41F021F8809 for ; Fri, 4 Jan 2013 21:29:54 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id x2so14531522iad.27 for ; Fri, 04 Jan 2013 21:29:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=aurlkeVlbudEVpiIOY+FTf6g1u4/RMrluZ9vz03lqX4=; b=M6P79VXeSNb280y2st3Q9YZGtOYF1zVMkLcECldOuaI5EPU0rh9PfkN8zpHpEGOqR5 kY5ioBe4rDjaGweQHZ86ahhWd7LoO5Xbjaj1Sh7yZ0M3Ml91gcP8j9QU/ELNFx2D7hIG gvgATNoF5GXQsLgORsNdZKx3WtqXm33VupyamN7NrJvsSGz00s6W8l8Cu6fOudjZqS4e AHd4M8hlhu7n4R4862ynNEEsAE3Ty1jsHMC655/ix5ZKIbLTDZICGcIfynz2NJzmLYBf sk6ap0zDjExEk/4yzapJHPWTSBLDrqSLmWthx0VbzlLeGxQmqZpdkfAVbdjILSm4a7sC a3yw== MIME-Version: 1.0 X-Received: by 10.50.170.102 with SMTP id al6mr743982igc.70.1357363785841; Fri, 04 Jan 2013 21:29:45 -0800 (PST) Received: by 10.64.132.33 with HTTP; Fri, 4 Jan 2013 21:29:45 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <20130105003432.GJ25817@verdi> References: <059d01cdead5$676701f0$363505d0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14E005@eusaamb109.ericsson.se> <20130105003432.GJ25817@verdi> Date: Sat, 5 Jan 2013 00:29:45 -0500 Message-ID: From: Jeff Wheeler To: John Leslie , Jakob Heitz , Chris Hall Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmeyhr5zyYMwswqfcZxgnnGqPueo+qmNqfzqWY6DTpclCfrcwSLwDYfufUs02iU8YprHuyz Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 05:29:59 -0000 On Fri, Jan 4, 2013 at 7:34 PM, John Leslie wrote: > Lacking a TLV structure for messages, we should not let go of a > marker which separates messages. Even if you were inventing "BGP 5" and you cleaned up all the messy extensions and implied field lengths, I think you would be persuaded to keep MARKER around as a good "dummy check" on the message stream. Historically, protocol designers have often conserved octets because it seems like a good way to keep protocol overhead low. For control-plane protocols whose encoding/transmission overhead is insignificant, this has sometimes produced poor results. On Fri, Jan 4, 2013 at 7:49 PM, Jakob Heitz wrote: > Sorry, that's not what I meant. > I meant a future operational message that says > "this update message caused me a problem and here is > the update message for your reference". It is a copy of > the message, not actually a replay. I liked your idea the first time I read it, and I continue to like it. This would be VERY helpful for troubleshooting. We had some discussion before about what would happen if the original message, being echoed back in a "this was broken" for diagnostic purposes, could not fit into the maximum message length for the session. What if you didn't include the original Message header, the MARKER, Message Type and Length? Your "broken message" echo Message would then be exactly the same Length as the bad one so it would definitely fit in the maximum length, and you don't need to tell the other side what the original Length was because it will know by the Length of your echo Message. As long as it is only for "broken UPDATE" and not for other kinds of messages, then you don't need to encode the Message Type field. The only downside is it wouldn't work for anything except a broken UPDATE, and it would need to be extended in the future if new types of messages are added to BGP. These seem like reasonable limitations though. On Fri, Jan 4, 2013 at 6:44 PM, Chris Hall wrote: > An option to resync on Marker etc, as a last-ditch, > keep-the-session-up-at-all-costs measure, doesn't seem that difficult > to me -- and wouldn't (key consideration) interfere with code for > normal running. I don't think it's that difficult either, but I do not know if the cost of implementing it is worth the reward. Attribute errors are things that, historically, we've seen propagate through the DFZ (and they might inside a datacenter network too) and the cost of dealing with them is probably going to be worthwhile. A message length error isn't going to cascade through anybody's network right now, let alone cross domain boundaries; so is it worth doing? I only brought up re-sync because it is possible to do and it might have some limited value if we had Jakob's "i got this bad message, here it is" feature. I'm still not necessarily advocating the re-sync idea. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From jakob.heitz@ericsson.com Fri Jan 4 21:50:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D072921F84B2; Fri, 4 Jan 2013 21:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9UaOHTJIVU7; Fri, 4 Jan 2013 21:50:18 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E695921F8480; Fri, 4 Jan 2013 21:50:17 -0800 (PST) Received: from EUSAAHC007.ericsson.se ([147.117.188.93]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r0564G1a019852; Sat, 5 Jan 2013 00:04:17 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Sat, 5 Jan 2013 00:50:08 -0500 From: Jakob Heitz To: Jeff Wheeler , John Leslie , Chris Hall Thread-Topic: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN6wW4ArX4RXLSC02HvqTfuOalqpg6OUkQ Date: Sat, 5 Jan 2013 05:50:07 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14E2CE@eusaamb109.ericsson.se> References: <059d01cdead5$676701f0$363505d0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14E005@eusaamb109.ericsson.se> <20130105003432.GJ25817@verdi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 05:50:19 -0000 On Friday, January 04, 2013 9:30 PM, Jeff Wheeler wrote: > Jakob's "i got this bad message, here it is" feature. Just to set the record straight, it's not my idea and I was referring to the older discussion about this. I'll note that=20 http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 has expired. It would be a good complement to http://tools.ietf.org/html/draft-ietf-idr-error-handling-03 if it were revived. --=20 Jakob Heitz. From john@jlc.net Sat Jan 5 03:50:50 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FE921F86E8; Sat, 5 Jan 2013 03:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.372 X-Spam-Level: X-Spam-Status: No, score=-106.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqwq0HXQ3e3a; Sat, 5 Jan 2013 03:50:50 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id EAD1921F8481; Sat, 5 Jan 2013 03:50:49 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 90AF333D56; Sat, 5 Jan 2013 06:50:49 -0500 (EST) Date: Sat, 5 Jan 2013 06:50:49 -0500 From: John Leslie To: Jakob Heitz Message-ID: <20130105115049.GK25817@verdi> References: <059d01cdead5$676701f0$363505d0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14E005@eusaamb109.ericsson.se> <20130105003432.GJ25817@verdi> <2F3EBB88EC3A454AAB08915FBF0B8C7E14E0BC@eusaamb109.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14E0BC@eusaamb109.ericsson.se> User-Agent: Mutt/1.4.1i Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 11:50:50 -0000 Jakob Heitz wrote: > On Friday, January 04, 2013 4:35 PM, John Leslie wrote: > >> Replay of an errant update can't help, and would likely crash its >> receiver. Don't do that! > > Sorry, that's not what I meant. > I meant a future operational message that says > "this update message caused me a problem and here is > the update message for your reference". It is a copy of > the message, not actually a replay. Danger, Will Robinson! Actually, we could invent a message type which reflects the content of a "bad" update, but it would only be useful for logging at the sending peer for human perusal; and, to be useful to that human it would need to classify the problem and indicate what part(s) of the update have been acted upon. Under no circumstances should we do this without making its length abundantly clear -- both the length we assumed when reading it and the length of what we are returning (which need not be the same: humans get the best value out of the first few hundred bytes in most cases). In particular, if we detect 16-bytes of marker within it, we MUST NOT return that marker un-escaped. This would probably be the most helpful when we _don't_ expect to be able to continue without a NOTIFY. We would need to send this only to a peer that advertised the capability to log it; and that might include the ability to recognize it _after_ the NOTIFY if we decide that sending it before the NOTIFY is too risky... -- John Leslie From rjs@rob.sh Sat Jan 5 05:31:50 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF9421F8473; Sat, 5 Jan 2013 05:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsvsMA5-LXoN; Sat, 5 Jan 2013 05:31:49 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id DC8A821F843B; Sat, 5 Jan 2013 05:31:48 -0800 (PST) Received: from [46.65.174.229] (helo=[172.16.1.8]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1TrTnb-0004pq-1s; Sat, 05 Jan 2013 13:28:31 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14E2CE@eusaamb109.ericsson.se> Date: Sat, 5 Jan 2013 13:31:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <128732A4-0343-4022-88E0-A21004D173DC@rob.sh> References: <059d01cdead5$676701f0$363505d0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14E005@eusaamb109.ericsson.se> <20130105003432.GJ25817@verdi> <2F3EBB88EC3A454AAB08915FBF0B8C7E14E2CE@eusaamb109.ericsson.se> To: Jakob Heitz X-Mailer: Apple Mail (2.1257) Cc: "idr@ietf.org" , "grow@ietf.org" , John Leslie Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 13:31:50 -0000 Hi Jakob, We (the authors) are working on a re-spin of this draft. My aim is to do = this within the next week or so. Kind regards, r. On 5 Jan 2013, at 05:50, Jakob Heitz wrote: > On Friday, January 04, 2013 9:30 PM, Jeff Wheeler = wrote: >=20 >> Jakob's "i got this bad message, here it is" feature. >=20 > Just to set the record straight, it's not my idea and > I was referring to the older discussion about this. >=20 > I'll note that=20 > http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 > has expired. It would be a good complement to > http://tools.ietf.org/html/draft-ietf-idr-error-handling-03 > if it were revived. >=20 > --=20 > Jakob Heitz. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jsw@inconcepts.biz Sat Jan 5 09:26:05 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918FC21F859D for ; Sat, 5 Jan 2013 09:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-zoGeerYR7E for ; Sat, 5 Jan 2013 09:26:05 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id EAEE421F8589 for ; Sat, 5 Jan 2013 09:26:04 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id 16so20935047iea.26 for ; Sat, 05 Jan 2013 09:26:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=bfGk1aICDFT6p2hipYjC6leGnTqt089Av7AEDQCs2Ck=; b=pExxCJAvxvZUYbb1MuC1zHUHvTIwIYoZy3aKin4d4PbrIKnq3YuC6ehUUJ9IQ4bXrq m0tpDhRLt4P5QqdoM8RV8daHLlqaz8cTDF+cFutncIo/FoTlane6Kf03nptRihWZUqot tudnk3f587F4S5L/H4y3rjuxYDSt2eN2RRWqW3bWkwrlbYecXWOmA7+XMlhmptd8G+L1 jfUzJjhpVWoGVqShBPtN80Snvuo3qTDveeawhe8HIjFXlHNBMwHIsZf8ADijfgPfmI8U 8wc17Iq0weSY73cEx0ZMgERq/4cEYa2SwwRLJTS7AICmImN490JzkTLZ77HFh3xMAbZQ v+pw== MIME-Version: 1.0 Received: by 10.50.152.240 with SMTP id vb16mr1858328igb.45.1357406764469; Sat, 05 Jan 2013 09:26:04 -0800 (PST) Received: by 10.64.132.33 with HTTP; Sat, 5 Jan 2013 09:26:04 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <20130105115049.GK25817@verdi> References: <059d01cdead5$676701f0$363505d0$@highwayman.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14E005@eusaamb109.ericsson.se> <20130105003432.GJ25817@verdi> <2F3EBB88EC3A454AAB08915FBF0B8C7E14E0BC@eusaamb109.ericsson.se> <20130105115049.GK25817@verdi> Date: Sat, 5 Jan 2013 12:26:04 -0500 Message-ID: From: Jeff Wheeler To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnNBWy/DeyGCm9wKg+oPLU0bNE9rTdUBdj+lMeNdvilhqUYd33dJuYl3BIDzrcLFrDHsT88 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 17:26:05 -0000 On Sat, Jan 5, 2013 at 6:50 AM, John Leslie wrote: > Actually, we could invent a message type which reflects the content > of a "bad" update, but it would only be useful for logging at the > sending peer for human perusal; and, to be useful to that human it > would need to classify the problem and indicate what part(s) of the > update have been acted upon. I don't think the message necessarily has to describe the problem, but BGP already has some mechanisms for this. If a receiver detects a malformed attribute, it will send a Notification with the bad attribute in the Data part of the notice. So the existing Notification will at least tell you about that. Imagine if you are an ISP and your customer's router is complaining of bad messages and resetting the session. His logging is not good so you don't have very much information to go on. Maybe you get a malformed attribute notice but your routers don't have any way for you to search for what paths carry that attribute. You will be debugging for a while! If the customer's router sent you the whole message you could troubleshoot the problem more quickly even if the customer router doesn't tell you why it choked on the message or produce any useful log entries for the customer tech. > Under no circumstances should we do this without making its length > abundantly clear -- both the length we assumed when reading it and the > length of what we are returning (which need not be the same: humans > get the best value out of the first few hundred bytes in most cases). > In particular, if we detect 16-bytes of marker within it, we MUST NOT > return that marker un-escaped. I agree that returning the un-escaped MARKER could have unintended consequences! I think the whole message is useful ESPECIALLY if the NLRI are moved to the beginning of messages at some time in the future. After all, if they are moved, then attributes will be at the end of the message, so you might need them. If the "oh no" message is literally the bad message with a different Message Type, then you will get everything including what the receiver thought the length was. The only things you will not get is the original marker and message type. If you only generate "oh no" if the marker is believed to be legit and the Message Type was UPDATE, then these are implicit whenever you get an "oh no" message. > This would probably be the most helpful when we _don't_ expect to > be able to continue without a NOTIFY. We would need to send this only > to a peer that advertised the capability to log it; and that might > include the ability to recognize it _after_ the NOTIFY if we decide > that sending it before the NOTIFY is too risky... Actually if error-handling introduces the ability to treat-as-withdraw or ignore-bad-message then it seems like it will become useful to have this new diagnostic message even if the BGP session is not reset. That way both sides of the session have some diagnostic information about problems that are potentially being masked by the use of error-handling. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From brian.e.carpenter@gmail.com Mon Jan 7 07:25:22 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA72121F86AC; Mon, 7 Jan 2013 07:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.306 X-Spam-Level: X-Spam-Status: No, score=-100.306 tagged_above=-999 required=5 tests=[AWL=-1.385, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXrSFkAZIbvr; Mon, 7 Jan 2013 07:25:22 -0800 (PST) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id C703D21F8751; Mon, 7 Jan 2013 07:25:18 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so2390749wgb.2 for ; Mon, 07 Jan 2013 07:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MCHbWu7di9fSLwICiyE/T2a/lfTN/RBjqaPwDeSK6Pw=; b=iySk6LfLVYMWS4HDfGx9dgCP8/V07F8xx3S/XO6ZZ0XmlTKT8v/wu+N+ezlaxdcA5Z fez96W1Rh2IVxSMOm8tyoihdbrs+K//nJV+i+cFX9mMNJPlWQbTu2TgBUYEjcgQxKza+ Stg8bsyllwHS5WFSZXniIepPEMvUApAcADdkTvkE6tJtqnEp7BcVnqN5SZgeTkD8R6M+ kDVOqGdInVlnsdtzrOHXMDepp9+DRKZy1cYoD+1gWRMaQMxV6GVThRSpzf/QzMIrVeAR SQizCiKVG7H9HkrUrPeuv8nRptrziKIJRGnc7er5qP+wyZWHYBwZtY77uad6uPf6GW6l 7eVw== X-Received: by 10.180.81.39 with SMTP id w7mr10009421wix.15.1357572312290; Mon, 07 Jan 2013 07:25:12 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-246.as13285.net. [2.102.219.246]) by mx.google.com with ESMTPS id fv2sm12615716wib.4.2013.01.07.07.25.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jan 2013 07:25:11 -0800 (PST) Message-ID: <50EAE8D9.5090200@gmail.com> Date: Mon, 07 Jan 2013 15:25:13 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-ietf-idr-sla-exchange.all@tools.ietf.org References: <20130103205630.3871.46704.idtracker@ietfa.amsl.com> In-Reply-To: <20130103205630.3871.46704.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, tsvwg-chairs@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-sla-exchange-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:25:22 -0000 Hi, I don't understand which reference model for inter-domain SLAs is being used here. There is an arbitrary list of element types (IP_DSCP, MPLS_TC, 802_1Q_COS, 802_1Q_DEI, PHB_ID) and then an arbitrary list of some QoS metrics. Presumably some of those metrics map on to some of the element types, but it isn't obvious and I am certain there are gaps. I don't think you can answer this with the text at the end of Section 6: > There are well-defined recommendations that exist for traffic class > mapping between two technologies. Receiver MAY use those defined > recommendations for traffic class mapping or MAY define its own as > per its network Traffic Class service definition to map to advertised > Traffic Classes. It is completely up to the receiver how to define > such traffic class mapping. Firstly, if there are such recommendations, they should be given as references. Secondly, why was the arbitrary set of QoS metrics chosen and how do we know that they are necessary and sufficient? (For example, I don't see any metric for drop rate, and for some traffic classes that is an important metric.) I think this draft needs to be discussed in TSVWG before it goes much further. A consistent model for QoS metric signalling is needed before we standardise a mapping onto IDR. Nits ---- [RFC2474], [RFC2475] and [RFC3140] are listed as references (presumably for IP_DSCP and PHB_ID) but they are not cited in the text. That will not get through the final ID-nits check. Also [RFC2475] is listed as a Normative reference, but it should be Informative. Why is [RFC3552] listed as a reference? Why is *obsoleted* [RFC1771] listed as a reference? Why is [RFC4760] *not* listed, since this needs to work for IPv6? The English in this draft is quite painful in many places. Here is one sentence chosen at random: > Taking same voice service as an > example, given Provider already may provision definition of EF code- > point for such, signaling this code-point traffic class from PE to CE > along with low latency service definition, omits administrator at the > CE to worry about such translation. I'm guessing that this means: Taking voice service as an example, a given provider might already provision the EF code- point for such traffic. Signaling the code-point for this traffic class from PE to CE, with a low latency service definition, would avoid manual operations by the administrator at the CE. Please run ID-nits and fix the 2 errors and 11 warnings. Regards Brian Carpenter From shares@ndzh.com Mon Jan 7 11:31:28 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC52821F8A45 for ; Mon, 7 Jan 2013 11:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.46 X-Spam-Level: *** X-Spam-Status: No, score=3.46 tagged_above=-999 required=5 tests=[AWL=1.465, BAYES_05=-1.11, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxsKaWY8s35W for ; Mon, 7 Jan 2013 11:31:27 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8830B21F8A42 for ; Mon, 7 Jan 2013 11:31:27 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=173.10.34.181; From: "Susan Hares" To: "idr wg" Date: Mon, 7 Jan 2013 14:31:19 -0500 Message-ID: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01CDECE3.A91269E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3tDXDBNQ2m6YB3SR2ENK4IPDGzag== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'John G. Scudder'" Subject: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 19:31:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001D_01CDECE3.A91269E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Idr folks: May the new year sparkle with joy for you-all. Our discussion on the lower-order four bits came to resolution to clarify the RFC 4721 text. John and I decided the best way to make sure all parties agree to the solution is to float a mini-draft that summaries this editorial fix to RFC4721. Because the mini-draft is so simple, we're going to do a 2 WG adoption and LC call combined. If anyone objects, we'll drop back to just a 2 week WG adoption. The draft name is: Update Attribute Flag Low Bits Clarification draft-hares-idr-update-attrib-low-bits-fix-00 gotten at : http://datatracker.ietf.org/doc/draft-hares-idr-update-attrib-low-bits-fix/ Purpose is: This draft provides an update to RFC 4721 to clarify the use of the lower-order four bits of the Attribute flag in the Update message. Authors: John Scudder and Sue Hares Comment early and often. Sue Hares and John Scudder ------=_NextPart_000_001D_01CDECE3.A91269E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Idr folks: =

 

May the new year = sparkle with joy for you-all.

 

Our discussion on = the lower-order four bits came to resolution

to clarify the RFC 4721 text. John and I decided the best way =

to make sure all = parties agree to the solution is to float

a mini-draft that summaries this editorial fix to = RFC4721.

 

Because the = mini-draft is so simple, we’re going to do a =

2 WG adoption and = LC call combined.  If anyone objects, = we’ll

drop back to just a = 2 week WG adoption. 

 

The draft name is: = 

 
 Update Attribute =
Flag Low Bits Clarification
 =
draft-hares-idr-update-attrib-low-bits-fix-00

 

gotten at = :

 

http://datatracker.ietf.org/doc/draft-hares-idr-update-attrib= -low-bits-fix/

 

 

Purpose is: =

 

  This draft = provides an update to RFC 4721 to clarify the use of = the

   = lower-order four bits of the Attribute flag in the Update = message.

 

Authors: John = Scudder and Sue Hares

 

Comment early and = often.

 

 

Sue Hares = and  John Scudder

------=_NextPart_000_001D_01CDECE3.A91269E0-- From john@jlc.net Mon Jan 7 12:22:35 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF5021F86F7 for ; Mon, 7 Jan 2013 12:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIm1uCfD0WbD for ; Mon, 7 Jan 2013 12:22:32 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 546A021F84D9 for ; Mon, 7 Jan 2013 12:22:28 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4A12533E30; Mon, 7 Jan 2013 15:22:28 -0500 (EST) Date: Mon, 7 Jan 2013 15:22:28 -0500 From: John Leslie To: Susan Hares Message-ID: <20130107202228.GD47093@verdi> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> User-Agent: Mutt/1.4.1i Cc: idr wg , "'John G. Scudder'" Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 20:22:35 -0000 Susan Hares wrote: > > Our discussion on the lower-order four bits came to resolution > to clarify the RFC 4721 text. John and I decided the best way > to make sure all parties agree to the solution is to float > a mini-draft that summaries this editorial fix to RFC4721. > > Because the mini-draft is so simple, we're going to do a > 2 WG adoption and LC call combined. If anyone objects, we'll > drop back to just a 2 week WG adoption. > > The draft name is: > Update Attribute Flag Low Bits Clarification > draft-hares-idr-update-attrib-low-bits-fix-00 I think we will need to back off the "MUST propagate these flags as received". We are going to have, for a number of years, legacy equipment which resets these bits to zero when propagating: after all, it's 100% compliant with 4271 to do so. Also, I don't think we can be sure that some modification of these bits in propagation will never prove useful. I suggest changing that MUST to a SHOULD: " " The lower-order four bits of the Attribute Flags octet are " unused. They MUST be zero when originated. When received, any " value MUST be accepted. When a BGP speaker propagates an " attribute, it SHOULD propagate these flags as received. -- John Leslie From randy@psg.com Mon Jan 7 13:02:16 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57C621F850B for ; Mon, 7 Jan 2013 13:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQDNQaBS0gQn for ; Mon, 7 Jan 2013 13:02:16 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC2021F8614 for ; Mon, 7 Jan 2013 13:02:15 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TsJpl-000J4K-MR; Mon, 07 Jan 2013 21:02:14 +0000 Date: Tue, 08 Jan 2013 06:02:12 +0900 Message-ID: From: Randy Bush To: "Susan Hares" In-Reply-To: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , "'John G. Scudder'" Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:02:17 -0000 > When a BGP speaker propagates an attribute, it MUST propagate these > flags as received. this precludes future use where the semantics include [further] signaling by non-originating hops. randy From chris.hall@highwayman.com Mon Jan 7 13:05:14 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EDF21F8900 for ; Mon, 7 Jan 2013 13:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0C+J0M5tDhcb for ; Mon, 7 Jan 2013 13:05:14 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tch.inty.net [91.221.169.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0218321F88FB for ; Mon, 7 Jan 2013 13:05:13 -0800 (PST) Received: from mdfmta009.tch.inty.net (unknown [127.0.0.1]) by mdfmta009.tch.inty.net (Postfix) with ESMTP id D3FAE12846D for ; Mon, 7 Jan 2013 21:05:11 +0000 (GMT) Received: from mdfmta009.tch.inty.net (unknown [127.0.0.1]) by mdfmta009.tch.inty.net (Postfix) with ESMTP id 768EB12846A for ; Mon, 7 Jan 2013 21:05:11 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tch.inty.net (Postfix) with ESMTP for ; Mon, 7 Jan 2013 21:05:11 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1TsJsc-00016r-Nq for idr@ietf.org; Mon, 07 Jan 2013 21:05:10 +0000 From: "Chris Hall" To: "'idr wg'" References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> In-Reply-To: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> Date: Mon, 7 Jan 2013 21:04:59 -0000 Organization: Highwayman Message-ID: <004601cded1a$adfbdef0$09f39cd0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBMhac0XhAnKoHOyYB3aId+E7wFplXuOXA Content-Language: en-gb X-MDF-HostID: 22 Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:05:14 -0000 So: The lower-order four bits of the Attribute Flags octet are unused. They MUST be zero when originated. When received, any value MUST be accepted. When a BGP speaker propagates an attribute, it MUST propagate these flags as received. When a route learned by iBGP is sent to a Confederation Peer (same Confederation, different Member AS), the LOCAL_PREF may be the same as when it was received, or may have been changed in the meantime. Is that origination or propagation ? A Route Reflector SHOULD NOT change the LOCAL_PREF, but if it does, what then ? And does it make a difference if the LOCAL_PREF is set (eg by a Route-Map) but the new value happens to be the same as the old one ? For an AS_PATH attribute, the originator of the route must be originating the attribute. Where the AS_PATH is passed on unchanged, that looks like propagating the attribute. But when it is updated, I assume that's propagating ? What about adding/removing Confederation Segments. And Route Reflector ORIGINATOR_ID and CLUSTER_LIST ? (OK, ORIGINATOR_ID is supposed to be passed unchanged... so propagating may be obvious, in that case.) And COMMUNITIES ? If those pass through unchanged, that looks like propagating ? But what level of change counts as originating ? And don't get me started on Extended Communities, where the transitiveness goes down to the individual community level. Given the historic confusion, and the small matter of no previous definition of "originating" or "propagating" an attribute, it seems to me that this is not a clarification but is retrofitting a new requirement. Currently there is no need to store the state of the flags with the attribute they rode in with. This new requirement changes that. Yuck :-( Chris From jgs@juniper.net Mon Jan 7 13:12:20 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727E321F845A for ; Mon, 7 Jan 2013 13:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_2=2.5, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yagkTHzTRx+m for ; Mon, 7 Jan 2013 13:12:14 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id D6DBE21F8487 for ; Mon, 7 Jan 2013 13:12:13 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUOs6Jl5FcADoOAx4Bqmt04P3ZVaB7gbW@postini.com; Mon, 07 Jan 2013 13:12:13 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 7 Jan 2013 13:10:51 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 7 Jan 2013 13:10:50 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.182) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 7 Jan 2013 13:13:00 -0800 Received: from mail179-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 Jan 2013 21:10:50 +0000 Received: from mail179-ch1 (localhost [127.0.0.1]) by mail179-ch1-R.bigfish.com (Postfix) with ESMTP id 45B3318015F for ; Mon, 7 Jan 2013 21:10:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zz98dI9371Ic85fh1432I4015Izz1de0h1202h1e76h1d1ah1d2ah1082kzz8275bhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h1504h1537h162dh1631h1662h1758h1155h) Received: from mail179-ch1 (localhost.localdomain [127.0.0.1]) by mail179-ch1 (MessageSwitch) id 1357593048277316_1458; Mon, 7 Jan 2013 21:10:48 +0000 (UTC) Received: from CH1EHSMHS033.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail179-ch1.bigfish.com (Postfix) with ESMTP id 37E00C0076; Mon, 7 Jan 2013 21:10:48 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by CH1EHSMHS033.bigfish.com (10.43.70.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 7 Jan 2013 21:10:47 +0000 Received: from [172.23.7.252] (66.129.224.36) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.245.2; Mon, 7 Jan 2013 21:10:46 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_0D09EDDD-E49B-47FE-A683-AEFE97F5312F" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Scudder In-Reply-To: Date: Mon, 7 Jan 2013 16:10:42 -0500 Message-ID: <0B000A61-2F53-476B-8742-6722AD566A3C@juniper.net> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> To: Randy Bush X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NDZH.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%PSG.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: idr wg , Hares Susan Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:12:20 -0000 --Apple-Mail=_0D09EDDD-E49B-47FE-A683-AEFE97F5312F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Jan 7, 2013, at 4:02 PM, Randy Bush wrote: >> When a BGP speaker propagates an attribute, it MUST propagate these >> flags as received. >=20 > this precludes future use where the semantics include [further] > signaling by non-originating hops. [and John Leslie made a similar remark] It doesn't really. Future use would update both 4271 and this spec, so = it would supersede what's written here. I tried writing it out with a = SHOULD, but it ended up seeming a bit silly: "... SHOULD propagate these flags as received, although future = extensions MAY define different semantics for one or more of these = flags, in which case those semantics should be applied instead." Thing is, every line of every spec the IETF has ever produced is subject = to later revision, at least in principle. So why make a special point of = calling it out here? Thanks, --John= --Apple-Mail=_0D09EDDD-E49B-47FE-A683-AEFE97F5312F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" randy@psg.com> wrote:
When a BGP speaker propagates an attribute, it MUST = propagate these
flags as received.

this precludes = future use where the semantics include [further]
signaling by = non-originating hops.

[and John Leslie = made a similar remark]

It doesn't really. = Future use would update both 4271 and this spec, so it would supersede = what's written here. I tried writing it out with a SHOULD, but it ended = up seeming a bit silly:

"... SHOULD propagate = these flags as received, although future extensions MAY define different = semantics for one or more of these flags, in which case those semantics = should be applied instead."

Thing is, every = line of every spec the IETF has ever produced is subject to later = revision, at least in principle. So why make a special point of calling = it out = here?

Thanks,

--John= --Apple-Mail=_0D09EDDD-E49B-47FE-A683-AEFE97F5312F-- From Donald.Smith@CenturyLink.com Mon Jan 7 13:50:16 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923CD21F84D8 for ; Mon, 7 Jan 2013 13:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzYWbIj0SB3L for ; Mon, 7 Jan 2013 13:50:16 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id D5D5821F8496 for ; Mon, 7 Jan 2013 13:50:15 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r07LoAaw024121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2013 14:50:11 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 512E41E0066; Mon, 7 Jan 2013 15:50:05 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 229921E0079; Mon, 7 Jan 2013 15:50:05 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r07Lo4ev017164; Mon, 7 Jan 2013 15:50:04 -0600 (CST) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.qintra.com [151.119.128.28]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r07Lo4UA017129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jan 2013 15:50:04 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.02.0318.001; Mon, 7 Jan 2013 14:50:03 -0700 From: "Smith, Donald" To: John Scudder , Randy Bush Thread-Topic: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: AQHN7RpPOkBH3nZy10GU0yawoV++epg+0goA//+UIWQ= Date: Mon, 7 Jan 2013 21:50:02 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A2A1932@PDDCWMBXEX503.ctl.intranet> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> , <0B000A61-2F53-476B-8742-6722AD566A3C@juniper.net> In-Reply-To: <0B000A61-2F53-476B-8742-6722AD566A3C@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.131] Content-Type: multipart/alternative; boundary="_000_68EFACB32CF4464298EA2779B058889D0A2A1932PDDCWMBXEX503ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: idr wg , Hares Susan Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 21:50:16 -0000 --_000_68EFACB32CF4464298EA2779B058889D0A2A1932PDDCWMBXEX503ct_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would rather they "must be zero when sent" as the original draft ALSO sta= tes. I know of vendors that do that, others that see anything not zero as m= alformed and drops the sessions, still others ignore and pass it on. If routers forward/re-announce as is many systems today will reset the sess= ion and begin flapping:( Or let me ask this differently. Is there a way to make your changes but giv= e the vendors time to address old incorrect interpretations? (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com ________________________________ From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of John Scudder= [jgs@juniper.net] Sent: Monday, January 07, 2013 2:10 PM To: Randy Bush Cc: idr wg; Hares Susan Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. On Jan 7, 2013, at 4:02 PM, Randy Bush = > wrote: When a BGP speaker propagates an attribute, it MUST propagate these flags as received. this precludes future use where the semantics include [further] signaling by non-originating hops. [and John Leslie made a similar remark] It doesn't really. Future use would update both 4271 and this spec, so it w= ould supersede what's written here. I tried writing it out with a SHOULD, b= ut it ended up seeming a bit silly: "... SHOULD propagate these flags as received, although future extensions M= AY define different semantics for one or more of these flags, in which case= those semantics should be applied instead." Thing is, every line of every spec the IETF has ever produced is subject to= later revision, at least in principle. So why make a special point of call= ing it out here? Thanks, --John --_000_68EFACB32CF4464298EA2779B058889D0A2A1932PDDCWMBXEX503ct_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I would rather they "must be zero when sent" as the origi= nal draft ALSO states. I know of vendors that do that, others that see anyt= hing not zero as malformed and drops the sessions, still others ignore and = pass it on.

 

If routers forward/re-announce as is many systems today will reset the s= ession and begin flapping:(

 

Or let me ask this differently. Is there a way to make your changes but = give the vendors time to address old incorrect interpretations?

 

 

 

(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centuryl= ink.com
From: idr-bounces@ietf.org [idr-bounces@ie= tf.org] on behalf of John Scudder [jgs@juniper.net]
Sent: Monday, January 07, 2013 2:10 PM
To: Randy Bush
Cc: idr wg; Hares Susan
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

On Jan 7, 2013, at 4:02 PM, Randy Bush <randy@psg.com> wrote:

When a BGP speaker propagates an attribute, it MU= ST propagate these
flags as received.

this precludes future use where the semantics include [further]
signaling by non-originating hops.

[and John Leslie made a similar remark]

It doesn't really. Future use would update both 4271 and this spec, so= it would supersede what's written here. I tried writing it out with a SHOU= LD, but it ended up seeming a bit silly:

"... SHOULD propagate these flags as received, although future ex= tensions MAY define different semantics for one or more of these flags, in = which case those semantics should be applied instead."

Thing is, every line of every spec the IETF has ever produced is subje= ct to later revision, at least in principle. So why make a special point of= calling it out here?

Thanks,

--John
--_000_68EFACB32CF4464298EA2779B058889D0A2A1932PDDCWMBXEX503ct_-- From brian.peter.dickson@gmail.com Mon Jan 7 14:11:44 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA6E11E809A for ; Mon, 7 Jan 2013 14:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDZWB3X4NlHY for ; Mon, 7 Jan 2013 14:11:43 -0800 (PST) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA6821F8684 for ; Mon, 7 Jan 2013 14:11:42 -0800 (PST) Received: by mail-ee0-f50.google.com with SMTP id b45so9641795eek.37 for ; Mon, 07 Jan 2013 14:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RmHM41x9DIjENhyNsa7+D4UQt2N0P5jMDyVYIJcFZME=; b=ZA6hqoc/6zeN6Cdn1hz02SwK2QiZsp1rxd4vYVpQCiMoS9VCx4UWwVKrEU/RTdSGsu Vgv+z2lwgEZDKfZKLooofl5A8YOzATsTASypVHTm7e3h/MEwzduuSReg0OfOHKHSRWhq Dc2QFj0m0uaKqfaZWosGqcoW1nlNfz1VHIvJb+uE0nUo9Evs75O5+aGS8Vfc6g427xgX 1F1JsiyzH/TJ3MtOXy4nXWYH2ULoYQUKG2hYLgJ16vaSQxifxqfelFnMusBsCy5qbU1k Tepu//0bHOKW7Qtxy0FYQjWy96d4cLOmRY40XcHK/VofA9wk8/auJyP8AoMz0gyxWCz/ TjEA== MIME-Version: 1.0 Received: by 10.14.173.69 with SMTP id u45mr168666538eel.21.1357596702289; Mon, 07 Jan 2013 14:11:42 -0800 (PST) Received: by 10.223.173.199 with HTTP; Mon, 7 Jan 2013 14:11:42 -0800 (PST) In-Reply-To: <20130107202228.GD47093@verdi> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> Date: Mon, 7 Jan 2013 17:11:42 -0500 Message-ID: From: Brian Dickson To: John Leslie Content-Type: multipart/alternative; boundary=047d7b6039f43030ca04d2ba1df8 Cc: idr wg , "John G. Scudder" , Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 22:11:44 -0000 --047d7b6039f43030ca04d2ba1df8 Content-Type: text/plain; charset=ISO-8859-1 I have an open question, primarily intended for the folks "experimenting" across the Internet (and causing much excitement): If there is even the slightest possibility of using some of these bits in future, REGARDLESS of for what, maybe the need to use them across unaware parties could be signalled/negotiated? For example, a new Capability to be negotiated, call it DONT_MESS_WITH. If negotiated, the unambiguous behavior of "pass unchanged" applies to the bits in question. In any other case, any presumption about the bits getting through should not be made, and the current "MUST BE ZERO" should apply to all. This would then mean, if NOT negotiated, allow any, but it is okay to stomp on them (but not required!!). If the folks USING the bits really want to do more experiments and/or use them, a quick I-D on the new Capability would be nice, and I would support it. While I would lean towards ALWAYS zeroing out the bits, I can see the argument the other way, and am fine with the current draft in LC, regardless of whether it is SHOULD or MUST. Brian On Mon, Jan 7, 2013 at 3:22 PM, John Leslie wrote: > Susan Hares wrote: > > > > Our discussion on the lower-order four bits came to resolution > > to clarify the RFC 4721 text. John and I decided the best way > > to make sure all parties agree to the solution is to float > > a mini-draft that summaries this editorial fix to RFC4721. > > > > Because the mini-draft is so simple, we're going to do a > > 2 WG adoption and LC call combined. If anyone objects, we'll > > drop back to just a 2 week WG adoption. > > > > The draft name is: > > Update Attribute Flag Low Bits Clarification > > draft-hares-idr-update-attrib-low-bits-fix-00 > > I think we will need to back off the "MUST propagate these flags > as received". > > We are going to have, for a number of years, legacy equipment > which resets these bits to zero when propagating: after all, it's > 100% compliant with 4271 to do so. Also, I don't think we can be > sure that some modification of these bits in propagation will never > prove useful. > > I suggest changing that MUST to a SHOULD: > " > " The lower-order four bits of the Attribute Flags octet are > " unused. They MUST be zero when originated. When received, any > " value MUST be accepted. When a BGP speaker propagates an > " attribute, it SHOULD propagate these flags as received. > > -- > John Leslie > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7b6039f43030ca04d2ba1df8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have an open question, primarily intended for the folks "experimenti= ng" across the Internet (and causing much excitement):

<= div>If there is even the slightest possibility of using some of these bits = in future, REGARDLESS of for what, maybe the need to use them across unawar= e parties could be signalled/negotiated?

For example, a new Capability to be negotiated, call it= DONT_MESS_WITH.

If negotiated, the unambiguous be= havior of "pass unchanged" applies to the bits in question.

In any other case, any presumption about the bits getti= ng through should not be made, and the current "MUST BE ZERO" sho= uld apply to all.

This would then mean, if NOT neg= otiated, allow any, but it is okay to stomp on them (but not required!!).

If the folks USING the bits really want to do more expe= riments and/or use them, a quick I-D on the new Capability would be nice, a= nd I would support it.

While I would lean towards = ALWAYS zeroing out the bits, I can see the argument the other way, and am f= ine with the current draft in LC, regardless of whether it is SHOULD or MUS= T.

Brian

On Mon, Jan 7, = 2013 at 3:22 PM, John Leslie <john@jlc.net> wrote:
Susan Hares <shares= @ndzh.com> wrote:
>
> Our discussion on the lower-order four bits came to resolution
> to clarify the RFC 4721 text. John and I decided the best way
> to make sure all parties agree to the solution is to float
> a mini-draft that summaries this editorial fix to RFC4721.
>
> Because the mini-draft is so simple, we're going to do a
> 2 WG adoption and LC call combined. =A0If anyone objects, we'll > drop back to just a 2 week WG adoption.
>
> The draft name is:
> =A0Update Attribute Flag Low Bits Clarification
> =A0draft-hares-idr-update-attrib-low-bits-fix-00

=A0 =A0I think we will need to back off the "MUST propagate thes= e flags
as received".

=A0 =A0We are going to have, for a number of years, legacy equipment
which resets these bits to zero when propagating: after all, it's
100% compliant with 4271 to do so. Also, I don't think we can be
sure that some modification of these bits in propagation will never
prove useful.

=A0 =A0I suggest changing that MUST to a SHOULD:
"
" The lower-order four bits of the Attribute Flags octet are
" unused. =A0They MUST be zero when originated. =A0When received, any<= br> " value MUST be accepted. =A0When a BGP speaker propagates an
" attribute, it SHOULD propagate these flags as received.

--
John Leslie <john@jlc.net>
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--047d7b6039f43030ca04d2ba1df8-- From farmer@umn.edu Mon Jan 7 15:28:14 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F6521F87E1 for ; Mon, 7 Jan 2013 15:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJOzJq-ks1YC for ; Mon, 7 Jan 2013 15:28:14 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4808021F87E0 for ; Mon, 7 Jan 2013 15:28:14 -0800 (PST) Received: from mail-ie0-f200.google.com (mail-ie0-f200.google.com [209.85.223.200]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 7 Jan 2013 17:28:03 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f200.google.com [209.85.223.200] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f200.google.com with SMTP id k13so82249162iea.3 for ; Mon, 07 Jan 2013 15:28:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=QG8riDE7+86ix2ZepojOHmIh4gGt4rFqNEZLEzlytDA=; b=Sq0LhUe43PVGkRxj6potqwJmVQu5DtGL4n1rGVvdsrUt6izwMq6VCxf/Fi5AHn+wQy mM3eJ+FwnXbJXk2m97Tk5uk2OfM88F41lRitE5A7aeYtyh3DYynXNwrmjRVlU0zti2hl nRvlzWdOYmTCHlZrvdj+S5H9Ys2yevFttrArMCjBG0nd16bHwbhmo1pmgnkDCL6YIxZ/ cbYL8CmRM2KqrOQ3AI4Dvjaeb72meNyilfpLg6U82NxXR8BYTvXJEgZ9MH0wrr9yAR2D PMInt6lSoGFljeBWKbsZEfQg39efrrgrbgzd6WxSQ/x3yRB3K1hcGFre58oTqXujdVq1 sTFA== X-Received: by 10.50.237.104 with SMTP id vb8mr7097812igc.11.1357601283181; Mon, 07 Jan 2013 15:28:03 -0800 (PST) X-Received: by 10.50.237.104 with SMTP id vb8mr7097805igc.11.1357601283084; Mon, 07 Jan 2013 15:28:03 -0800 (PST) Received: from x-134-84-88-28.nts.umn.edu ([2607:ea00:101:2001:d8dc:ac7b:d909:ac25]) by mx.google.com with ESMTPS id c3sm8527409igj.1.2013.01.07.15.28.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jan 2013 15:28:02 -0800 (PST) Message-ID: <50EB5A01.9090702@umn.edu> Date: Mon, 07 Jan 2013 17:28:01 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: John Scudder References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <0B000A61-2F53-476B-8742-6722AD566A3C@juniper.net> In-Reply-To: <0B000A61-2F53-476B-8742-6722AD566A3C@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkHR97HViiG+rA6UPjnrO8I1UHDoDS9APyS9TGwvrPDC2QAu3OlzJGD+3zCH7PkKHbaAvK9CeMOyOXJkjpAl3nycQXIP3qC/SlQh8ytXcfc3OTYl0EKYVjsX6HnQswlZMgtLv3r Cc: idr wg , Hares Susan Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 23:28:15 -0000 On 1/7/13 15:10 , John Scudder wrote: > On Jan 7, 2013, at 4:02 PM, Randy Bush > wrote: > >>> When a BGP speaker propagates an attribute, it MUST propagate these >>> flags as received. >> >> this precludes future use where the semantics include [further] >> signaling by non-originating hops. > > [and John Leslie made a similar remark] > > It doesn't really. Future use would update both 4271 and this spec, so > it would supersede what's written here. ... > Thing is, every line of every spec the IETF has ever produced is subject > to later revision, at least in principle. So why make a special point of > calling it out here? I agree this is how an update should happen. However, thinking about my response to Randy a little more, I would suggest the following additional clarification; The lower-order four bits of the Attribute Flags octet are currently unused flags. These unused flags MUST be zero when originated. When received, any value MUST be accepted for these unused flags. When a BGP speaker propagates these unused flags, they MUST be propagated as received. This way if a new specification only defined the use of (bit 5) per se, and doesn't actually update the first sentence of this paragraph then it is still clear what the intent is. Furthermore, adding "currently" to the first sentence moves the focus of the paragraph from defining specifically which bits are unused to the appropriate behavior for unused flags, whichever are unused at the moment. As you say, a proper update should "update both 4271 and this spec." However, I could easily see a new specification only defining the new bit and forgetting to update the first sentence of this paragraph. Especially if the update is self-contained and not a holistic RFC 4721bis type update. So, while I agree that we shouldn't specifically call-out that this "is subject to later revision" However, a little strategic use of language can ensure that the intent remains clear even if future changes aren't as clean as we would hope. By the way, I support this Draft for both WG adoption & WGLC, as I believe the changes I'm suggesting are really just editorial in nature. Thanks -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jakob.heitz@ericsson.com Mon Jan 7 16:06:21 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F196B21F8726 for ; Mon, 7 Jan 2013 16:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQrZUKknPeEf for ; Mon, 7 Jan 2013 16:06:20 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9C821F871D for ; Mon, 7 Jan 2013 16:06:20 -0800 (PST) Received: from EUSAAHC007.ericsson.se ([147.117.188.93]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id r0806EW1013950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jan 2013 18:06:15 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Mon, 7 Jan 2013 19:04:37 -0500 From: Jakob Heitz To: Brian Dickson , John Leslie Thread-Topic: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: Ac3tDXDBNQ2m6YB3SR2ENK4IPDGzagAMS6MAAAPQnwAABtFUUA== Date: Tue, 8 Jan 2013 00:04:37 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E152A60@eusaamb109.ericsson.se> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E152A60eusaamb109ericsso_" MIME-Version: 1.0 Cc: idr wg , Susan Hares , "John G. Scudder" Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 00:06:21 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E152A60eusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's too late. Those bits are dead. There's plenty more bits in the sea. Even if your peer supports them, your peer's peer might not. Even for non-transitive attributes. The best we can do is set them to 0, so nothing breaks. -- Jakob Heitz. ________________________________ From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Brian= Dickson Sent: Monday, January 07, 2013 2:12 PM To: John Leslie Cc: idr wg; John G. Scudder; Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. I have an open question, primarily intended for the folks "experimenting" a= cross the Internet (and causing much excitement): If there is even the slightest possibility of using some of these bits in f= uture, REGARDLESS of for what, maybe the need to use them across unaware pa= rties could be signalled/negotiated? For example, a new Capability to be negotiated, call it DONT_MESS_WITH. If negotiated, the unambiguous behavior of "pass unchanged" applies to the = bits in question. In any other case, any presumption about the bits getting through should no= t be made, and the current "MUST BE ZERO" should apply to all. This would then mean, if NOT negotiated, allow any, but it is okay to stomp= on them (but not required!!). If the folks USING the bits really want to do more experiments and/or use t= hem, a quick I-D on the new Capability would be nice, and I would support i= t. While I would lean towards ALWAYS zeroing out the bits, I can see the argum= ent the other way, and am fine with the current draft in LC, regardless of = whether it is SHOULD or MUST. Brian On Mon, Jan 7, 2013 at 3:22 PM, John Leslie > wrote: Susan Hares > wrote: > > Our discussion on the lower-order four bits came to resolution > to clarify the RFC 4721 text. John and I decided the best way > to make sure all parties agree to the solution is to float > a mini-draft that summaries this editorial fix to RFC4721. > > Because the mini-draft is so simple, we're going to do a > 2 WG adoption and LC call combined. If anyone objects, we'll > drop back to just a 2 week WG adoption. > > The draft name is: > Update Attribute Flag Low Bits Clarification > draft-hares-idr-update-attrib-low-bits-fix-00 I think we will need to back off the "MUST propagate these flags as received". We are going to have, for a number of years, legacy equipment which resets these bits to zero when propagating: after all, it's 100% compliant with 4271 to do so. Also, I don't think we can be sure that some modification of these bits in propagation will never prove useful. I suggest changing that MUST to a SHOULD: " " The lower-order four bits of the Attribute Flags octet are " unused. They MUST be zero when originated. When received, any " value MUST be accepted. When a BGP speaker propagates an " attribute, it SHOULD propagate these flags as received. -- John Leslie > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E152A60eusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It's too late. Those bit= s are dead. There's plenty more bits in the sea.
 
Even if your peer suppor= ts them, your peer's peer might not.
Even for non-transitive = attributes.
The best we can do is se= t them to 0, so nothing breaks.

-- Jakob Heitz.

 

From: idr-bounces@ietf.org [mailto:= idr-bounces@ietf.org] On Behalf Of Brian Dickson
Sent: Monday, January 07, 2013 2:12 PM
To: John Leslie
Cc: idr wg; John G. Scudder; Susan Hares
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

I have an open question, primarily intended for the folks "experimenti= ng" across the Internet (and causing much excitement):

If there is even the slightest possibility of using some of these bits= in future, REGARDLESS of for what, maybe the need to use them across unawa= re parties could be signalled/negotiated?

For example, a new Capability to be negotiated, call it DONT_MESS_WITH= .

If negotiated, the unambiguous behavior of "pass unchanged" = applies to the bits in question.

In any other case, any presumption about the bits getting through shou= ld not be made, and the current "MUST BE ZERO" should apply to al= l.

This would then mean, if NOT negotiated, allow any, but it is okay to = stomp on them (but not required!!).

If the folks USING the bits really want to do more experiments and/or = use them, a quick I-D on the new Capability would be nice, and I would supp= ort it.

While I would lean towards ALWAYS zeroing out the bits, I can see the = argument the other way, and am fine with the current draft in LC, regardles= s of whether it is SHOULD or MUST.

Brian

On Mon, Jan 7, 2013 at 3:22 PM, John Leslie <john@jlc.net><= /span> wrote:
Susan Hares <shares= @ndzh.com> wrote:
>
> Our discussion on the lower-order four bits came to resolution
> to clarify the RFC 4721 text. John and I decided the best way
> to make sure all parties agree to the solution is to float
> a mini-draft that summaries this editorial fix to RFC4721.
>
> Because the mini-draft is so simple, we're going to do a
> 2 WG adoption and LC call combined.  If anyone objects, we'll
> drop back to just a 2 week WG adoption.
>
> The draft name is:
>  Update Attribute Flag Low Bits Clarification
>  draft-hares-idr-update-attrib-low-bits-fix-00

   I think we will need to back off the "MUST propagate thes= e flags
as received".

   We are going to have, for a number of years, legacy equipment<= br> which resets these bits to zero when propagating: after all, it's
100% compliant with 4271 to do so. Also, I don't think we can be
sure that some modification of these bits in propagation will never
prove useful.

   I suggest changing that MUST to a SHOULD:
"
" The lower-order four bits of the Attribute Flags octet are
" unused.  They MUST be zero when originated.  When received= , any
" value MUST be accepted.  When a BGP speaker propagates an
" attribute, it SHOULD propagate these flags as received.

--
John Leslie <john@jlc.net>
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E152A60eusaamb109ericsso_-- From shyam.ioml@gmail.com Mon Jan 7 16:50:03 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1602D1F0CF6 for ; Mon, 7 Jan 2013 16:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLOwgKCagfbt for ; Mon, 7 Jan 2013 16:50:02 -0800 (PST) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id EFC6C1F0CF5 for ; Mon, 7 Jan 2013 16:50:01 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id b13so20280093vby.33 for ; Mon, 07 Jan 2013 16:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rZGiwvGfAxLjC77FzLej/KFvn0hqbb4VWY+CRQzddMY=; b=W1NXbs2QA3ytRFHHUu/s0YGqu3UuEyzROdQU65w79JDjpTQ2O0uzMQYAswwLkBPwsT ymnhJtuYFO835eJf6i7EBrTp9P1Sw5JNn/6EugVHSrWCiBE/WoqXg57ixHA0mCr0vhbY 48pH/SdJIQa9iNxiQySjE6pI4Qb81GD7nRT90PM38Gh20OOk94XynpHEV19F42GqvTs9 wh+XRPvVndhrp6ByM6w6yZZVykkMrbm6Y61Rc5+5lFzWX061RgTq1qz6xbJ7Gkz5p+G7 oc9AYKFiW2oD49JNZyc6NzecdX+kVaLm6Nxh+y8i2wu0dqpq4Qi1cxRKDNDjp1VOK0VR dW+Q== MIME-Version: 1.0 Received: by 10.52.32.229 with SMTP id m5mr74548583vdi.5.1357606201297; Mon, 07 Jan 2013 16:50:01 -0800 (PST) Received: by 10.58.46.238 with HTTP; Mon, 7 Jan 2013 16:50:01 -0800 (PST) In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E152A60@eusaamb109.ericsson.se> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <2F3EBB88EC3A454AAB08915FBF0B8C7E152A60@eusaamb109.ericsson.se> Date: Mon, 7 Jan 2013 16:50:01 -0800 Message-ID: From: Shyam Sethuram To: Jakob Heitz Content-Type: multipart/alternative; boundary=bcaec51d21025f8a7d04d2bc5304 Cc: "John G. Scudder" , idr wg , Susan Hares , John Leslie Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 00:50:03 -0000 --bcaec51d21025f8a7d04d2bc5304 Content-Type: text/plain; charset=ISO-8859-1 Agree. At best you can mandate "MUST propagate unchanged" for unrecognized transitive attributes. For recognized attributes, it would be upto the implementation to do what it pleases -- this could be based on attribute type for newer attributes (if at all). shyam On Mon, Jan 7, 2013 at 4:04 PM, Jakob Heitz wrote: > ** > It's too late. Those bits are dead. There's plenty more bits in the sea. > > Even if your peer supports them, your peer's peer might not. > Even for non-transitive attributes. > The best we can do is set them to 0, so nothing breaks. > > -- > Jakob Heitz. > > > ------------------------------ > *From:* idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] *On Behalf Of *Brian > Dickson > *Sent:* Monday, January 07, 2013 2:12 PM > *To:* John Leslie > *Cc:* idr wg; John G. Scudder; Susan Hares > *Subject:* Re: [Idr] 2 week WG adoption & LC on > draft-hares-idr-update-attrib-low-bits-fix-00. > > I have an open question, primarily intended for the folks > "experimenting" across the Internet (and causing much excitement): > > If there is even the slightest possibility of using some of these bits > in future, REGARDLESS of for what, maybe the need to use them across > unaware parties could be signalled/negotiated? > > For example, a new Capability to be negotiated, call it DONT_MESS_WITH. > > If negotiated, the unambiguous behavior of "pass unchanged" applies to > the bits in question. > > In any other case, any presumption about the bits getting through should > not be made, and the current "MUST BE ZERO" should apply to all. > > This would then mean, if NOT negotiated, allow any, but it is okay to > stomp on them (but not required!!). > > If the folks USING the bits really want to do more experiments and/or > use them, a quick I-D on the new Capability would be nice, and I would > support it. > > While I would lean towards ALWAYS zeroing out the bits, I can see the > argument the other way, and am fine with the current draft in LC, > regardless of whether it is SHOULD or MUST. > > Brian > > On Mon, Jan 7, 2013 at 3:22 PM, John Leslie wrote: > >> Susan Hares wrote: >> > >> > Our discussion on the lower-order four bits came to resolution >> > to clarify the RFC 4721 text. John and I decided the best way >> > to make sure all parties agree to the solution is to float >> > a mini-draft that summaries this editorial fix to RFC4721. >> > >> > Because the mini-draft is so simple, we're going to do a >> > 2 WG adoption and LC call combined. If anyone objects, we'll >> > drop back to just a 2 week WG adoption. >> > >> > The draft name is: >> > Update Attribute Flag Low Bits Clarification >> > draft-hares-idr-update-attrib-low-bits-fix-00 >> >> I think we will need to back off the "MUST propagate these flags >> as received". >> >> We are going to have, for a number of years, legacy equipment >> which resets these bits to zero when propagating: after all, it's >> 100% compliant with 4271 to do so. Also, I don't think we can be >> sure that some modification of these bits in propagation will never >> prove useful. >> >> I suggest changing that MUST to a SHOULD: >> " >> " The lower-order four bits of the Attribute Flags octet are >> " unused. They MUST be zero when originated. When received, any >> " value MUST be accepted. When a BGP speaker propagates an >> " attribute, it SHOULD propagate these flags as received. >> >> -- >> John Leslie >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --bcaec51d21025f8a7d04d2bc5304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agree.
At best you can mandate "MUST propagate unchange= d" for unrecognized transitive attributes.
For recognized at= tributes, it would be upto the implementation to do what it pleases -- this= could
be based on attribute type for newer attributes (if at all).
=A0
shyam

On Mon, Jan 7,= 2013 at 4:04 PM, Jakob Heitz <jakob.heitz@ericsson.com> wrote:
It's too late. Those bits are dead. There's plenty more = bits in the sea.
=A0
Even if your peer supports them, your peer's peer might not.=
Even for non-transitive attributes.
The best we can do is set them to 0, so nothing breaks.

--
Jakob Heitz.

=A0

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Brian Dickson
Sent: Monday, January 07, 2013 2:12 PM
To: John Leslie
Cc: idr wg; John G. Scudder; Susan Hares
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

I have an open question, primarily intended for the folks "experimenti= ng" across the Internet (and causing much excitement):

If there is even the slightest possibility of using some of these bits= in future, REGARDLESS of for what, maybe the need to use them across unawa= re parties could be signalled/negotiated?

For example, a new Capability to be negotiated, call it DONT_MESS_WITH= .

If negotiated, the unambiguous behavior of "pass unchanged" = applies to the bits in question.

In any other case, any presumption about the bits getting through shou= ld not be made, and the current "MUST BE ZERO" should apply to al= l.

This would then mean, if NOT negotiated, allow any, but it is okay to = stomp on them (but not required!!).

If the folks USING the bits really want to do more experiments and/or = use them, a quick I-D on the new Capability would be nice, and I would supp= ort it.

While I would lean towards ALWAYS zeroing out the bits, I can see the = argument the other way, and am fine with the current draft in LC, regardles= s of whether it is SHOULD or MUST.

Brian

On Mon, Jan 7, 2013 at 3:22 PM, John Leslie <john@jlc.net><= /span> wrote:
Susan Hares <s= hares@ndzh.com> wrote:
>
> Our discussion on the lower-order four bits came to resolution
> to clarify the RFC 4721 text. John and I decided the best way
> to make sure all parties agree to the solution is to float
> a mini-draft that summaries this editorial fix to RFC4721.
>
> Because the mini-draft is so simple, we're going to do a
> 2 WG adoption and LC call combined. =A0If anyone objects, we'll > drop back to just a 2 week WG adoption.
>
> The draft name is:
> =A0Update Attribute Flag Low Bits Clarification
> =A0draft-hares-idr-update-attrib-low-bits-fix-00

=A0 =A0I think we will need to back off the "MUST propagate these flag= s
as received".

=A0 =A0We are going to have, for a number of years, legacy equipment
which resets these bits to zero when propagating: after all, it's
100% compliant with 4271 to do so. Also, I don't think we can be
sure that some modification of these bits in propagation will never
prove useful.

=A0 =A0I suggest changing that MUST to a SHOULD:
"
" The lower-order four bits of the Attribute Flags octet are
" unused. =A0They MUST be zero when originated. =A0When received, any<= br> " value MUST be accepted. =A0When a BGP speaker propagates an
" attribute, it SHOULD propagate these flags as received.

--
John Leslie <john@jlc.= net>
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


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


--bcaec51d21025f8a7d04d2bc5304-- From bruno.decraene@orange.com Tue Jan 8 00:53:10 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E3821F8833 for ; Tue, 8 Jan 2013 00:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzhv9EaD+oVy for ; Tue, 8 Jan 2013 00:53:08 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7945B21F8830 for ; Tue, 8 Jan 2013 00:53:07 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0D6F03B4755; Tue, 8 Jan 2013 09:53:06 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D758527C0B1; Tue, 8 Jan 2013 09:53:05 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 09:53:05 +0100 From: To: Susan Hares , "'John G. Scudder'" Thread-Topic: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: Ac3tDXDBNQ2m6YB3SR2ENK4IPDGzagAbFhSA Date: Tue, 8 Jan 2013 08:53:04 +0000 Message-ID: <25434_1357635185_50EBDE71_25434_13095_3_53C29892C857584299CBF5D05346208A1229AD@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> In-Reply-To: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1229ADPEXCVZYM11corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.8.70315 Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 08:53:10 -0000 --_000_53C29892C857584299CBF5D05346208A1229ADPEXCVZYM11corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Susan, John, I support this draft (WG adoption & WG LC). IMHO, it clarifies the original meaning of RFC 4271. (i.e. "when sent" mean= t when originated) I'm not a big fan of the current =A73. Known BGP Implementation Habits - I would propose to move it to appendix. - "Habits" sound strange to me. But I'll leave English language to others. - IMHO the doc should clarify which behavior/habit is compliant with this d= ocument and which are not. - From a protocol/IETF standpoint, do have a consensus that this draft is m= erely a clarification i.e. we are not changing the RFC 4271 spec? or not? I= f the former, those behaviors are not "habits" but non compliant implementa= tions. This document is a clarification, so let's be clear. If the latter, = may be the document should not call this a clarification but a re-specifica= tion of those bits. I also agree with Chris, that we need to specify what is a propagation of a= n attribute vs a new (re)origination. E.g. if the value is changed, is this= a propagation or an re-origination? I'm not sure I have an opinion on this= . Eventually the draft could allow both. E.g. "SHOULD be propagated" (or re= -originated, but a SHOULD rather than a MUST). There had been a discussion about whether such clarification should be hand= led by a new draft or by an errata. What's the outcome / rule? Thanks, Regards, Bruno From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan= Hares Sent: Monday, January 07, 2013 8:31 PM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low= -bits-fix-00. Idr folks: May the new year sparkle with joy for you-all. Our discussion on the lower-order four bits came to resolution to clarify the RFC 4721 text. John and I decided the best way to make sure all parties agree to the solution is to float a mini-draft that summaries this editorial fix to RFC4721. Because the mini-draft is so simple, we're going to do a 2 WG adoption and LC call combined. If anyone objects, we'll drop back to just a 2 week WG adoption. The draft name is: Update Attribute Flag Low Bits Clarification draft-hares-idr-update-attrib-low-bits-fix-00 gotten at : http://datatracker.ietf.org/doc/draft-hares-idr-update-attrib-low-bits-fix/ Purpose is: This draft provides an update to RFC 4721 to clarify the use of the lower-order four bits of the Attribute flag in the Update message. Authors: John Scudder and Sue Hares Comment early and often. Sue Hares and John Scudder ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A1229ADPEXCVZYM11corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Susan, = John,

&n= bsp;

I suppo= rt this draft (WG adoption & WG LC).

&n= bsp;

IMHO, i= t clarifies the original meaning of RFC 4271. (i.e. "when sent" m= eant when originated)

&n= bsp;

I’= ;m not a big fan of the current =A73. Known BGP Implementation Habits<= /o:p>

- I wou= ld propose to move it to appendix.

- ̶= 0;Habits” sound strange to me. But I’ll leave English language = to others.

- IMHO = the doc should clarify which behavior/habit is compliant with this document= and which are not.

- From = a protocol/IETF standpoint, do have a consensus that this draft is merely a= clarification i.e. we are not changing the RFC 4271 spec? or not? If the f= ormer, those behaviors are not “habits” but non compliant implementations. This document is a clarification, so le= t’s be clear. If the latter, may be the document should not call this= a clarification but a re-specification of those bits.

&n= bsp;

I also = agree with Chris, that we need to specify what is a propagation of an attri= bute vs a new (re)origination. E.g. if the value is changed, is this a prop= agation or an re-origination? I’m not sure I have an opinion on this. Eventually the draft could allow both. E.g= . “SHOULD be propagated” (or re-originated, but a SHOULD rather= than a MUST).

&n= bsp;

&n= bsp;

There h= ad been a discussion about whether such clarification should be handled by = a new draft or by an errata. What’s the outcome / rule?

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, January 07, 2013 8:31 PM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] 2 week WG adoption & LC on draft-hares-idr-update= -attrib-low-bits-fix-00.

 

 

Idr folks:

 

May the new year sparkle with joy for you-a= ll.

 

Our discussion on the lower-order four bits= came to resolution

to clarify the RFC 4721 text. John and I de= cided the best way

to make sure all parties agree to the solut= ion is to float

a mini-draft that summaries this editorial = fix to RFC4721.

 

Because the mini-draft is so simple, weR= 17;re going to do a

2 WG adoption and LC call combined.  I= f anyone objects, we’ll

drop back to just a 2 week WG adoption.&nbs= p;

 

The draft name is: 

 
 Update Attribute Flag Low Bits Clarification
 draft-hares-idr-update-attrib-low-bits-fix-00

 

gotten at :

 

http://datatracker.ietf.org/do= c/draft-hares-idr-update-attrib-low-bits-fix/

 

 

Purpose is:

 

  This draft provides an update to RFC= 4721 to clarify the use of the

   lower-order four bits of the A= ttribute flag in the Update message.

 

Authors: John Scudder and Sue Hares

 

Comment early and often.<= /p>

 

 

Sue Hares and  John Scudde= r 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A1229ADPEXCVZYM11corpora_-- From bruno.decraene@orange.com Tue Jan 8 01:38:26 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363F421F87FD for ; Tue, 8 Jan 2013 01:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnoIg2zU8LBA for ; Tue, 8 Jan 2013 01:38:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 543E021F87ED for ; Tue, 8 Jan 2013 01:38:25 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 8BF4A18C961 for ; Tue, 8 Jan 2013 10:38:24 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 71C0427C095 for ; Tue, 8 Jan 2013 10:38:24 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 10:38:24 +0100 From: To: idr wg Thread-Topic: draft-ietf-idr-error-handling-03 Thread-Index: Ac3tg+b8D9KduKl0RleURWhwMdpTHA== Date: Tue, 8 Jan 2013 09:38:23 +0000 Message-ID: <25424_1357637904_50EBE910_25424_2266_1_53C29892C857584299CBF5D05346208A122A97@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.8.90315 Subject: [Idr] draft-ietf-idr-error-handling-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 09:38:26 -0000 Hi, The draft proposes to correct some errors in received BGP attribute, at lea= st for optional & transitive bits. While this looks good, it looks dangerous to me. Indeed, when a router perc= eives an error in the message received from a peer, we never know if the pe= rceived error is due to the sender, the receiver or the IETF specification.= There is a tendency to believe that the error is on the sender side, becau= se when I see an error, I tend to believe that I'm right and the other is w= rong. While in fact, we just don't know. So if I correct an error while _I_ (the receiver) was wrong, I introduce a = new error in the message. The issue is that each router in this BGP network= (e.g. Internet) having this implementation introduce an error. So the netw= ork has to handle N errors at the same time and this can have significant i= mpact especially for downstream implementations using RFC 4271 error handli= ng. As an illustration of attribute correction/overwriting: let's change the at= tribute length of this attribute 99 that I received (cf the RIPE_Labs incid= ent where the originator of the route was correct, but multiple propagators= changed the attribute and introduced an error) I'd rather propose to react to an error with treat as withdraw, rather than= try to correct it. In addition, for simplification (hence improved code reliability / easier t= esting) of the error handling code, I would tend to use treat as withdraw f= or all errors, rather than introducing "attribute discard" for a very few s= pecific cases (hence very limited improvement). Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bruno.decraene@orange.com Tue Jan 8 02:57:20 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838C521F8DAE; Tue, 8 Jan 2013 02:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWv5u8LVHQ1S; Tue, 8 Jan 2013 02:57:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A267121F8D8B; Tue, 8 Jan 2013 02:57:13 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 28B94338002; Tue, 8 Jan 2013 11:57:12 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E752835C102; Tue, 8 Jan 2013 11:57:08 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 11:57:08 +0100 From: To: Rob Shakir Thread-Topic: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN5GI5uUvvkzXFTkC50Ybfet8IiZg9vUmg Date: Tue, 8 Jan 2013 10:57:08 +0000 Message-ID: <31774_1357642629_50EBFB84_31774_520_1_53C29892C857584299CBF5D05346208A122AFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A122AFBPEXCVZYM11corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.31.121227 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 10:57:20 -0000 --_000_53C29892C857584299CBF5D05346208A122AFBPEXCVZYM11corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rob, all, Thanks for the updated document. New version is definitely an improvement. Thanks for the work. Please find below some comments. 1) Critical error (=A73) IMHO, the term "critical error" is mixing both technical/protocol considera= tions (e.g. can't read the update) and requirements considerations (BGP ses= sions state is too degraded and I prefer shutting it down rather than runni= ng on a degraded mode) which IMHO is unfortunate and does not help the disc= ussion. I'd much prefer that we distinguish both by defining technical leve= ls of errors and then defining the requirements for each plus the conseque= nces/drawbacks of the decision (whether to keep or shut the session). For the protocol standpoint, I would propose the following level of errors,= based on the protocol encoding layers: session, update, attribute. - attribute level error: semantic or syntax error in the attribute value or= attribute flags - session level error: error in the update length / marker. i.e. if skippin= g the update length I can't find the marker of the next bgp message. - update level error: any other error in the update message We can further distinguish if the NLRIs can be parsed or not. 2) Business Requirements In the current text, I found the requirements a bit too technically oriente= d. I'd rather add business requirements independent of the current solution= s. I would propose: In VPN networks, VPN are supposed to be isolated from each others and from = the others services (most notably the Internet). Hence, an error on routes/= BGP messages related to a VPN SHOULD NOT negatively impact others VPN. Simi= larly, an error on routes/BGP messages related to a non VPN service SHOULD = not negatively impact the VPN service. In Internet networks, ASes are supposed to be Autonomous. Hence an error on= routes/BGP messages originated by an AS SHOULD NOT negatively impact desti= nations originated from others ASes. By "negatively impact", we mean losing reachability for a destination (NLRI= ), typically by losing all the paths in the Loc-RIB to that destination (NL= RI). Note that those paths may be learnt through multiple BGP sessions and = hence the requirement span multiple BGP sessions. The consequence is that i= f the BGP error is believed to be limited to a single BGP session (e.g. a s= ession level error), then in a network with redundancy, the destination is = believed to be still known through another session and hence the session MA= Y be chosen to be shutdown and all path learned from that session removed. = On the contrary, if the BGP error has a chance to be also met on the redund= ant paths/sessions, then the BGP session and the routes learned from that s= ession SHOULD be preserved, until the negatives consequences are considered= too important. When evaluating those consequences, the fact that all redun= dant paths/sessions may suffer from the same error and hence will inherit t= he same decision MUST be considered. As an illustration, we typically seek to avoid that because of a single BGP= error a PE lose both its redundant iBGP session with its BGP RR. And by "a= PE" I really mean all PE experiencing this condition. Could easily be 10s = of PE, even 100s. 3) Technical requirements For session level error, the BGP session is dead so need to be shutdown/gra= ceful shutdown/graceful restart. If the update length is set to the number = of octets sent to the peer (or vice versa) rather than computed based on th= e content of the update, there is a chance to 1) limit the number of such s= ession level errors and 2) increase the probability that this error is loca= l to that session and not likely to happen on a redundant/backup session. T= here is probably a limited part of the BGP code which needs to be hardened = to reduce such unrecoverable errors. And if those errors are still frequent= , we may further propose technical solutions (e.g. replacing TCP by SCTP wh= ich can provides message boundaries, among others things (e.g. some benefit= s of multi-sessions)) For attribute & update level error when the NLRI can be parsed, cf draft-er= ror-handling (treat as withdraw). Now let the discussion begin :). For attribute & update level error when th= e NLRI cannot be extracted IMHO there is room for discussion and analysis o= f the consequences. "since the NLRI cannot be extracted, error handling mechanisms must be appl= ied at the per-session level" (=A75) Well, IMO, this is a choice to be made rather than a "must". If we were to skip a BGP update: For Internet, probably the worst case would be to miss a BGP update with a = loop in the AS path and hence create a loop for me and my upstream ASes for= the NLRI in the missed updated. How much probable is this? 0 for iBGP sess= ions. TBE for eBGP. Then what would be the consequences? loss of connectivi= ty for the NLRI until the problem is manually solved by an AS between the o= rigin and me, possible forwarding congestions for others. I'm not sure I ca= re too much about loosing reachability to NLRI in faulty BGP update as most= likely, if only one BGP update (out of millions) is faulty, the reason may= come from the origin AS playing with a specific bit or attribute and if th= ey chose to play with their update, they should bear the responsibility. To= be compared by the probability of losing all redundant paths (if the error= is seen on redundant path) and the consequences (PE -possibly all PEs- dow= n). For VPN, probably the worst case would be to keep a VPN label previously al= located to VPN 1 and re-allocated to another VPN (VPN breach Cf http://tool= s.ietf.org/html/draft-uttaro-idr-bgp-persistence-01#section-8) Again, the pro and con could be discussed (e.g. possibly one way partial VP= N breach for some time (that basically no one can exploit) vs all VPN/PE be= ing down. IMHO, if we believe such issue could be corrected in 30-60 minute= s, I would probably favor keeping the session up. >From the lively discussions, looks like the opinions may vary depending on = the AS, people and circumstances. E.g. how much my redundant BGP paths are = failure independent? (e.g. use different BGP implementations) As such, what about defining severity levels for BGP error handling? As one= may wish to accept only low severity errors while others may be willing to= accept high severity errors (including when the NLRI cannot be found) e.g.= the network has been down for 30 minutes, while waiting for the patch, one= may want to be able to restore some service at all costs (can't possibly b= e worst). Again, IMHO it would be good to discuss the drawbacks depending on the situ= ation (iBGP, eBGP; hop by hop routed, tunneled ...) in this requirement doc= ument to make sure we are all on the same page, we have constructive discus= sions and SP enabling revised error handling are fully aware of the consequ= ences. 4) Security consideration In =A77 "security considerations" I would discuss the fact that current BGP= error handling (or a (too) strict one) could be exploited by attackers to = create a remote DOS attack. Should we also ask a review of the SIDR WG since "The purpose of the SIDR w= orking group is to reduce vulnerabilities in the inter-domain routing syste= m." ? ... Best regards, Bruno >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rob >Shakir >Sent: Thursday, December 27, 2012 7:44 PM >To: idr@ietf.org >Subject: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-er= ror- >handling-06.txt > >Hi IDR! > >FYI -- please find an updated relating to a new version of draft-ietf-grow= -ops- >reqs-for-bgp-error-handling. > >Any comments very welcome (to me or grow@). > >Seasons greetings! >r. > >Begin forwarded message: > >> From: > >> Subject: Re: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error- >handling-06.txt >> Date: 27 December 2012 18:41:50 GMT >> To: >, > >> Cc: grow@ietf.org >> >> On 27/12/2012 18:35, "internet-drafts@ietf.org" > >> wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Global Routing Operations Working Group >>> of the IETF. >>> >>> Title : Operational Requirements for Enhanced Error Handling >>> Behaviour in BGP-4 >>> Author(s) : Rob Shakir >>> Filename : draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.= txt >>> Pages : 19 >>> Date : 2012-12-27 >> >> Hi GROW! >> >> This update is a fairly major re-spin of the BGP Error Handling >> requirements draft. The technical content should be as per the previous >> revisions however, following the ietf/RtgDir last call comments, I have >> made the following changes: >> >> * Made the amendments that were discussed and there was no disagreement >> with from our meeting in Atlanta -- this is essentially renaming the >> Critical/Semantic error types to Critical/Non-Critical. >> >> * Significant de-duplication within the text including merging the >> operational monitoring/toolset discussions into the error handling >> sections. >> >> * Adoption of rfc2119 language throughout to clarify the requirements. >> >> * Removal of some of the discussion around more detailed justifications >> for why particular decisions were made. I think this was useful through >> the discussion phase of this draft, but it seems like GROW/IDR have >> converged on a relatively stable set of requirements, so I have trimmed >> back some of this discussion. >> >> I'd really welcome any further comments on this before we re-submit for >> publication. To eke these out - Peter/Chris - can you kick off a WGLC for >> this draft please? :-) >> >> Seasons greetings! >> r. >> >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A122AFBPEXCVZYM11corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Rob, all,

 

Thanks for the updated docum= ent.

New version is definitely an= improvement. Thanks for the work.

Please find below some comme= nts.

 

 

1= )  Critical error (=A73)

 

IMHO, the term “critic= al error” is mixing both technical/protocol considerations (e.g. can&= #8217;t read the update) and requirements considerations (BGP sessions stat= e is too degraded and I prefer shutting it down rather than running on a degraded mode) which IMHO is unfortunate and does not he= lp the discussion. I’d much prefer that we distinguish both by defini= ng technical levels of errors and then defining the requirements for each p= lus  the consequences/drawbacks of the decision (whether to keep or shut the session).

For the protocol standpoint,= I would propose the following level of errors, based on the protocol encod= ing layers: session, update, attribute.

- attribute level error: sem= antic or syntax error in the attribute value or attribute flags<= /span>

- session level error: error= in the update length / marker. i.e. if skipping the update length I can= 217;t find the marker of the next bgp message.

- update level error: any ot= her error in the update message

 

We can further distinguish i= f the NLRIs can be parsed or not.

 

2= )  Business Requirements

In the current text, I found= the requirements a bit too technically oriented. I’d rather add busi= ness requirements independent of the current solutions. I would propose:

 

In VPN networks, VPN are sup= posed to be isolated from each others and from the others services (most no= tably the Internet). Hence, an error on routes/BGP messages related to a VP= N SHOULD NOT negatively impact others VPN. Similarly, an error on routes/BGP messages related to a non VPN servi= ce SHOULD not negatively impact the VPN service.

In Internet networks, ASes a= re supposed to be Autonomous. Hence an error on routes/BGP messages origina= ted by an AS SHOULD NOT negatively impact destinations originated from othe= rs ASes.

 

By “negatively impact&= #8221;, we mean losing reachability for a destination (NLRI), typically by = losing all the paths in the Loc-RIB to that destination (NLRI). Note that t= hose paths may be learnt through multiple BGP sessions and hence the requirement span multiple BGP sessions. The consequence is t= hat if the BGP error is believed to be limited to a single BGP session (e.g= . a session level error), then in a network with redundancy, the destinatio= n is believed to be still known through another session and hence the session MAY be chosen to be shutdown= and all path learned from that session removed. On the contrary, if the BG= P error has a chance to be also met on the redundant paths/sessions, then t= he BGP session and the routes learned from that session SHOULD be preserved, until the negatives consequences ar= e considered too important. When evaluating those consequences, the fact th= at all redundant paths/sessions may suffer from the same error and hence wi= ll inherit the same decision MUST be considered.

 

As an illustration, we typic= ally seek to avoid that because of a single BGP error a PE lose both its re= dundant iBGP session with its BGP RR. And by “a PE” I really me= an all PE experiencing this condition. Could easily be 10s of PE, even 100s.

 

3= )  Technical requirements<= o:p>

For session level error, the= BGP session is dead so need to be shutdown/graceful shutdown/graceful rest= art. If the update length is set to the number of octets sent to the peer (= or vice versa) rather than computed based on the content of the update, there is a chance to 1) limit the numb= er of such session level errors and 2) increase the probability that this e= rror is local to that session and not likely to happen on a redundant/backu= p session. There is probably a limited part of the BGP code which needs to be hardened to reduce such unrecoverab= le errors. And if those errors are still frequent, we may further propose t= echnical solutions (e.g. replacing TCP by SCTP which can provides message b= oundaries, among others things (e.g. some benefits of multi-sessions))

 

For attribute & update l= evel error when the NLRI can be parsed, cf draft-error-handling (treat as w= ithdraw).

 

Now let the discussion begin= J. For attribute & update level error when the NLRI canno= t be extracted IMHO there is room for discussion and analysis of the consequences.

 

“since the NLRI cannot be extracted, = error handling mechanisms must be applied at the per-session level” (= =A75)

Well, IMO, this is a choice = to be made rather than a “must”.

 

 

If we were to skip a BGP upd= ate:

For Internet, probably the w= orst case would be to miss a BGP update with a loop in the AS path and henc= e create a loop for me and my upstream ASes for the NLRI in the missed upda= ted. How much probable is this? 0 for iBGP sessions. TBE for eBGP. Then what would be the consequences? loss of = connectivity for the NLRI until the problem is manually solved by an AS bet= ween the origin and me, possible forwarding congestions for others. I’= ;m not sure I care too much about loosing reachability to NLRI in faulty BGP update as most likely, if only one BGP = update (out of millions) is faulty, the reason may come from the origin AS = playing with a specific bit or attribute and if they chose to play with the= ir update, they should bear the responsibility. To be compared by the probability of losing all redundant = paths (if the error is seen on redundant path) and the consequences (PE -po= ssibly all PEs- down).

 

For VPN, probably the worst = case would be to keep a VPN label previously allocated to VPN 1 and re-allo= cated to another VPN (VPN breach Cf http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01#section-8)

Again, the pro and con could= be discussed (e.g. possibly one way partial VPN breach for some time (that= basically no one can exploit) vs all VPN/PE being down. IMHO, if we believ= e such issue could be corrected in 30-60 minutes, I would probably favor keeping the session up.<= /p>

 

From the lively discussions,= looks like the opinions may vary depending on the AS, people and circumsta= nces. E.g. how much my redundant BGP paths are failure independent? (e.g. u= se different BGP implementations)

As such, what about defining= severity levels for BGP error handling? As one may wish to accept only low= severity errors while others may be willing to accept high severity errors= (including when the NLRI cannot be found) e.g. the network has been down for 30 minutes, while waiting for th= e patch, one may want to be able to restore some service at all costs (can&= #8217;t possibly be worst).

 

Again, IMHO it would be good= to discuss the drawbacks depending on the situation (iBGP, eBGP; hop by ho= p routed, tunneled …) in this requirement document to make sure we ar= e all on the same page, we have constructive discussions and SP enabling revised error handling are fully aware of the = consequences.

 

4= )  Security consideration<= o:p>

In =A77 “security cons= iderations” I would discuss the fact that current BGP error handling = (or a (too) strict one) could be exploited by attackers to create a remote = DOS attack.

Should we also ask a review = of the SIDR WG since “The purpose of the SIDR working group is to red= uce vulnerabilities in the inter-domain routing system.” ? ...

 

Best regards,

Bruno

 

 

 

 

 

 

 

 

 

 

 

 

 

 

>-----Original Message-----

>From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of R= ob

>Shakir

>Sent: Thursday, December 27, 2012 7:44 PM

>To: idr@ietf.org

>Subject: [Idr] Fwd: [GROW] I-D Action: draft-= ietf-grow-ops-reqs-for-bgp-error-

>handling-06.txt

> 

>Hi IDR!

> 

>FYI -- please find an updated relating to a n= ew version of draft-ietf-grow-ops-

>reqs-for-bgp-error-handling.

> 

>Any comments very welcome (to me or grow@).

> 

>Seasons greetings!

>r.

> 

>Begin forwarded message:

> 

>> From: <rob.shakir@bt.= com>

>> Subject: Re: [GROW] I-D Action: draft-ie= tf-grow-ops-reqs-for-bgp-error-

>handling-06.txt

>> Date: 27 December 2012 18:41:50 GMT=

>> To: <internet-= drafts@ietf.org>, <i-d-announce@ietf.o= rg>

>> Cc: grow@ietf.org=

>> 

>> On 27/12/2012 18:35, "internet-drafts@ietf.org" <internet-drafts@ietf.org>

>> wrote:

>> 

>>> 

>>> A New Internet-Draft is available fr= om the on-line Internet-Drafts

>>> directories.

>>> This draft is a work item of the Glo= bal Routing Operations Working Group

>>> of the IETF.

>>> 

>>>   Title    =        : Operational Requirements for Enhance= d Error Handling

>>> Behaviour in BGP-4

>>>   Author(s)   &n= bsp;   : Rob Shakir

>>>   Filename   &nb= sp;    : draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.= txt

>>>   Pages    =        : 19

>>>   Date    &= nbsp;       : 2012-12-27

>> 

>> Hi GROW!

>> 

>> This update is a fairly major re-spin of= the BGP Error Handling

>> requirements draft. The technical conten= t should be as per the previous

>> revisions however, following the ietf/Rt= gDir last call comments, I have

>> made the following changes:

>> 

>> * Made the amendments that were discusse= d and there was no disagreement

>> with from our meeting in Atlanta -- this= is essentially renaming the

>> Critical/Semantic error types to Critica= l/Non-Critical.

>> 

>> * Significant de-duplication within the = text including merging the

>> operational monitoring/toolset discussio= ns into the error handling

>> sections.

>> 

>> * Adoption of rfc2119 language throughou= t to clarify the requirements.

>> 

>> * Removal of some of the discussion arou= nd more detailed justifications

>> for why particular decisions were made. = I think this was useful through

>> the discussion phase of this draft, but = it seems like GROW/IDR have

>> converged on a relatively stable set of = requirements, so I have trimmed

>> back some of this discussion.=

>> 

>> I'd really welcome any further comments = on this before we re-submit for

>> publication. To eke these out - Peter/Ch= ris - can you kick off a WGLC for

>> this draft please? :-)

>> 

>> Seasons greetings!

>> r.

>> 

>> ________________________________________= _______

>> GROW mailing list

>> GROW@ietf.org

>> https:= //www.ietf.org/mailman/listinfo/grow

> 

>_____________________________________________= __

>Idr mailing list

>Idr@ietf.org

>https://www.= ietf.org/mailman/listinfo/idr

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A122AFBPEXCVZYM11corpora_-- From ietfc@btconnect.com Tue Jan 8 07:42:17 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A940121F8AC8 for ; Tue, 8 Jan 2013 07:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.689 X-Spam-Level: X-Spam-Status: No, score=-5.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVMtFGWJBYc5 for ; Tue, 8 Jan 2013 07:42:16 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id BE08121F8B37 for ; Tue, 8 Jan 2013 07:42:15 -0800 (PST) Received: from mail223-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Tue, 8 Jan 2013 15:42:15 +0000 Received: from mail223-tx2 (localhost [127.0.0.1]) by mail223-tx2-R.bigfish.com (Postfix) with ESMTP id 48D406800C9; Tue, 8 Jan 2013 15:42:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.181; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0711HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz98dI9371I542I1432Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh8275ch1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh304l1155h) Received: from mail223-tx2 (localhost.localdomain [127.0.0.1]) by mail223-tx2 (MessageSwitch) id 1357659732532701_3586; Tue, 8 Jan 2013 15:42:12 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.248]) by mail223-tx2.bigfish.com (Postfix) with ESMTP id 71BEE540063; Tue, 8 Jan 2013 15:42:12 +0000 (UTC) Received: from DBXPRD0711HT004.eurprd07.prod.outlook.com (157.56.254.181) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 8 Jan 2013 15:42:08 +0000 Received: from DB3PRD0411HT005.eurprd04.prod.outlook.com (157.56.253.53) by pod51017.outlook.com (10.255.178.37) with Microsoft SMTP Server (TLS) id 14.16.245.2; Tue, 8 Jan 2013 15:42:05 +0000 Message-ID: <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> From: t.petch To: John Leslie , Susan Hares References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> Date: Tue, 8 Jan 2013 15:39:42 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.53] X-OriginatorOrg: btconnect.com Cc: idr wg , "'John G. Scudder'" Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:42:17 -0000 ----- Original Message ----- From: "John Leslie" To: "Susan Hares" Cc: "idr wg" ; "'John G. Scudder'" Sent: Monday, January 07, 2013 8:22 PM > Susan Hares wrote: > > > > Our discussion on the lower-order four bits came to resolution > > to clarify the RFC 4721 text. John and I decided the best way > > to make sure all parties agree to the solution is to float > > a mini-draft that summaries this editorial fix to RFC4721. > > > > Because the mini-draft is so simple, we're going to do a > > 2 WG adoption and LC call combined. If anyone objects, we'll > > drop back to just a 2 week WG adoption. > > > > The draft name is: > > Update Attribute Flag Low Bits Clarification > > draft-hares-idr-update-attrib-low-bits-fix-00 > > I think we will need to back off the "MUST propagate these flags > as received". > > We are going to have, for a number of years, legacy equipment > which resets these bits to zero when propagating: after all, it's > 100% compliant with 4271 to do so. Also, I don't think we can be > sure that some modification of these bits in propagation will never > prove useful. > > I suggest changing that MUST to a SHOULD: > " > " The lower-order four bits of the Attribute Flags octet are > " unused. They MUST be zero when originated. When received, any > " value MUST be accepted. When a BGP speaker propagates an > " attribute, it SHOULD propagate these flags as received. Since we have two different ways of interpreting the current spec, any nailing down of the spec is going to make some implementations non-conforming; that is unavoidable. Looking to the future, the underlying question is whether or not we want to use the bits as optional transitive. If we do, then they should be propagated as received and we can have a progressive deployment of a new use. If we do not, then they should be propagated as zero and we cannot used them until all involved parties have been updated to understand them. So both approaches are right, depending on future use, and I do not know which is the right 'right' answer. SHOULD is a bit of a weasel word here, allowing some fence sitting. It seems a bit like fail-danger and fail-safe, more psychology than technology. Tom Petch > -- > John Leslie > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From shares@ndzh.com Tue Jan 8 08:11:15 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA17821F89CB for ; Tue, 8 Jan 2013 08:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.983 X-Spam-Level: * X-Spam-Status: No, score=1.983 tagged_above=-999 required=5 tests=[AWL=1.477, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRNJCwcvZBIV for ; Tue, 8 Jan 2013 08:11:13 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0519F21F8976 for ; Tue, 8 Jan 2013 08:11:12 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.199.73.120; From: "Susan Hares" To: "'Brian Dickson'" , "'John Leslie'" References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> In-Reply-To: Date: Tue, 8 Jan 2013 11:10:59 -0500 Message-ID: <00ae01cdedba$c038a490$40a9edb0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01CDED90.D763D510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBMhac0XhAnKoHOyYB3aId+E7wFgHJJ7KtAeUmB0KZO5yHEA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' , "'John G. Scudder'" Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 16:11:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AF_01CDED90.D763D510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Brian: Interesting idea. The reason for the RFC rather the errata was to clarify when an implementation supported this features. The capability extends my earlier idea from something that can be tracked on contracts to a capability. Eventually, we'll have a set of RFCs that provide Errata on the 4271 text with bits in this capability. The capability would signal on a peer basis what errata you support. I write up the capability and send it to you. Sue From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] Sent: Monday, January 07, 2013 5:12 PM To: John Leslie Cc: Susan Hares; idr wg; John G. Scudder Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. I have an open question, primarily intended for the folks "experimenting" across the Internet (and causing much excitement): If there is even the slightest possibility of using some of these bits in future, REGARDLESS of for what, maybe the need to use them across unaware parties could be signalled/negotiated? For example, a new Capability to be negotiated, call it DONT_MESS_WITH. If negotiated, the unambiguous behavior of "pass unchanged" applies to the bits in question. In any other case, any presumption about the bits getting through should not be made, and the current "MUST BE ZERO" should apply to all. This would then mean, if NOT negotiated, allow any, but it is okay to stomp on them (but not required!!). If the folks USING the bits really want to do more experiments and/or use them, a quick I-D on the new Capability would be nice, and I would support it. While I would lean towards ALWAYS zeroing out the bits, I can see the argument the other way, and am fine with the current draft in LC, regardless of whether it is SHOULD or MUST. Brian On Mon, Jan 7, 2013 at 3:22 PM, John Leslie wrote: Susan Hares wrote: > > Our discussion on the lower-order four bits came to resolution > to clarify the RFC 4721 text. John and I decided the best way > to make sure all parties agree to the solution is to float > a mini-draft that summaries this editorial fix to RFC4721. > > Because the mini-draft is so simple, we're going to do a > 2 WG adoption and LC call combined. If anyone objects, we'll > drop back to just a 2 week WG adoption. > > The draft name is: > Update Attribute Flag Low Bits Clarification > draft-hares-idr-update-attrib-low-bits-fix-00 I think we will need to back off the "MUST propagate these flags as received". We are going to have, for a number of years, legacy equipment which resets these bits to zero when propagating: after all, it's 100% compliant with 4271 to do so. Also, I don't think we can be sure that some modification of these bits in propagation will never prove useful. I suggest changing that MUST to a SHOULD: " " The lower-order four bits of the Attribute Flags octet are " unused. They MUST be zero when originated. When received, any " value MUST be accepted. When a BGP speaker propagates an " attribute, it SHOULD propagate these flags as received. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_00AF_01CDED90.D763D510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian:

 

Interesting idea.

 

The reason for the RFC rather the errata was to = clarify when an implementation supported this features. The capability = extends my earlier idea from something that can be tracked on contracts = to a capability.

 

Eventually, we’ll have a set of RFCs that = provide Errata on the 4271 text with bits in this capability. The = capability would signal on a peer basis what errata you support. =

 

I write up the capability and send it to you.  =

 

Sue

 

From:= = Brian Dickson [mailto:brian.peter.dickson@gmail.com]
Sent: = Monday, January 07, 2013 5:12 PM
To: John Leslie
Cc: = Susan Hares; idr wg; John G. Scudder
Subject: Re: [Idr] 2 week = WG adoption & LC on = draft-hares-idr-update-attrib-low-bits-fix-00.

 

I have an = open question, primarily intended for the folks = "experimenting" across the Internet (and causing much = excitement):

 

If there is even the slightest possibility of using = some of these bits in future, REGARDLESS of for what, maybe the need to = use them across unaware parties could be = signalled/negotiated?

 

For example, a new Capability to be negotiated, call = it DONT_MESS_WITH.

 

If negotiated, the unambiguous behavior of "pass = unchanged" applies to the bits in = question.

 

In any other case, any presumption about the bits = getting through should not be made, and the current "MUST BE = ZERO" should apply to all.

 

This would then mean, if NOT negotiated, allow any, = but it is okay to stomp on them (but not = required!!).

 

If the folks USING the bits really want to do more = experiments and/or use them, a quick I-D on the new Capability would be = nice, and I would support it.

 

While I would lean towards ALWAYS zeroing out the = bits, I can see the argument the other way, and am fine with the current = draft in LC, regardless of whether it is SHOULD or = MUST.

 

Brian

On Mon, Jan 7, 2013 at 3:22 PM, John Leslie <john@jlc.net> = wrote:

Susan Hares <shares@ndzh.com> = wrote:
>
> Our discussion on the lower-order four bits came = to resolution
> to clarify the RFC 4721 text. John and I decided = the best way
> to make sure all parties agree to the solution is = to float
> a mini-draft that summaries this editorial fix to = RFC4721.
>
> Because the mini-draft is so simple, we're = going to do a
> 2 WG adoption and LC call combined.  If = anyone objects, we'll
> drop back to just a 2 week WG = adoption.
>
> The draft name is:
>  Update = Attribute Flag Low Bits Clarification
> =  draft-hares-idr-update-attrib-low-bits-fix-00

<= p class=3DMsoNormal>   I think we will need to back off the = "MUST propagate these flags
as received".

  =  We are going to have, for a number of years, legacy = equipment
which resets these bits to zero when propagating: after = all, it's
100% compliant with 4271 to do so. Also, I don't think we = can be
sure that some modification of these bits in propagation will = never
prove useful.

   I suggest changing that MUST = to a SHOULD:
"
" The lower-order four bits of the = Attribute Flags octet are
" unused.  They MUST be zero when = originated.  When received, any
" value MUST be accepted. =  When a BGP speaker propagates an
" attribute, it SHOULD = propagate these flags as received.

--
John Leslie <john@jlc.net>
____________________= ___________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

------=_NextPart_000_00AF_01CDED90.D763D510-- From shares@ndzh.com Tue Jan 8 08:51:23 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A00021F86F7 for ; Tue, 8 Jan 2013 08:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.49 X-Spam-Level: * X-Spam-Status: No, score=1.49 tagged_above=-999 required=5 tests=[AWL=0.985, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiClW2HMY3AB for ; Tue, 8 Jan 2013 08:51:20 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9113221F867B for ; Tue, 8 Jan 2013 08:51:16 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.199.73.120; From: "Susan Hares" To: , "'John G. Scudder'" References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <25434_1357635185_50EBDE71_25434_13095_3_53C29892C857584299CBF5D05346208A1229AD@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <25434_1357635185_50EBDE71_25434_13095_3_53C29892C857584299CBF5D05346208A1229AD@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Tue, 8 Jan 2013 11:51:11 -0500 Message-ID: <00db01cdedc0$5e41b280$1ac51780$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DC_01CDED96.756E1B80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBMhac0XhAnKoHOyYB3aId+E7wFgKYokvUmUROTUA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 16:51:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DC_01CDED96.756E1B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno: =20 Thank you for feedback on the support of the bits=20 =20 Having lived through all the revisions of BGP, it was also my = recollection was that this was a clarification. John=92s memory matched mine.=20 =20 The reason for an RFC was to clearly draw a line when implementations = engage in enforcing this behavior. Please also take a look at the idea of capabilities signaling the specifics in error handling. I=92ll write-up = the draft on these issues.=20 =20 On paragraph 3 and habits - The discussion suggest I should consult the bgp-issues draft. During the RFC4271 creation we had a long email = thread that Andrew Lange captured in a document (bgp-issues). You may be able = to find an old copy of that draft. My recollection is that we discussed habits. Let me review that text and get back to you.=20 =20 By the way, Stewart Bryant asked for a reformatting of that bgp-issues = into one or more of the different forms (short review, web page, and a = clean-up longer version). I=92ll try to =93hurry=94 along that rewrite so we = can review it together.=20 =20 To clarify your question: =20 =93what is a propagation of an attribute vs a new (re)origination. E.g. = if the value is changed, is this a propagation or an re-origination?=94 =20 John said:=20 When a BGP speaker propagates an attribute, it MUST propagate these = flags as received. -------- =20 I agree we also need to clear up what=92s a propagation or a = re-origination. Are there some changes that you have operational concerns about (e.g. 2-byte/4byte AS changes, private AS stripping).=20 =20 Sue =20 =20 =20 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com Sent: Tuesday, January 08, 2013 3:53 AM To: Susan Hares; 'John G. Scudder' Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. =20 Susan, John, =20 I support this draft (WG adoption & WG LC). =20 IMHO, it clarifies the original meaning of RFC 4271. (i.e. "when sent" = meant when originated) =20 I=92m not a big fan of the current =A73. Known BGP Implementation Habits - I would propose to move it to appendix. - =93Habits=94 sound strange to me. But I=92ll leave English language to = others. - IMHO the doc should clarify which behavior/habit is compliant with = this document and which are not. - From a protocol/IETF standpoint, do have a consensus that this draft = is merely a clarification i.e. we are not changing the RFC 4271 spec? or = not? If the former, those behaviors are not =93habits=94 but non compliant implementations. This document is a clarification, so let=92s be clear. = If the latter, may be the document should not call this a clarification but a re-specification of those bits. =20 I also agree with Chris, that we need to specify what is a propagation = of an attribute vs a new (re)origination. E.g. if the value is changed, is = this a propagation or an re-origination? I=92m not sure I have an opinion on = this. Eventually the draft could allow both. E.g. =93SHOULD be propagated=94 = (or re-originated, but a SHOULD rather than a MUST). =20 =20 There had been a discussion about whether such clarification should be handled by a new draft or by an errata. What=92s the outcome / rule? =20 Thanks, Regards, Bruno =20 From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Susan Hares Sent: Monday, January 07, 2013 8:31 PM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. =20 =20 Idr folks:=20 =20 May the new year sparkle with joy for you-all.=20 =20 Our discussion on the lower-order four bits came to resolution=20 to clarify the RFC 4721 text. John and I decided the best way=20 to make sure all parties agree to the solution is to float a mini-draft that summaries this editorial fix to RFC4721. =20 Because the mini-draft is so simple, we=92re going to do a=20 2 WG adoption and LC call combined. If anyone objects, we=92ll drop back to just a 2 week WG adoption. =20 =20 The draft name is:=20 =20 Update Attribute Flag Low Bits Clarification draft-hares-idr-update-attrib-low-bits-fix-00 =20 gotten at : =20 http://datatracker.ietf.org/doc/draft-hares-idr-update-attrib-low-bits-fi= x/ =20 =20 Purpose is:=20 =20 This draft provides an update to RFC 4721 to clarify the use of the lower-order four bits of the Attribute flag in the Update message. =20 Authors: John Scudder and Sue Hares =20 Comment early and often. =20 =20 Sue Hares and John Scudder=20 _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. Thank you. ------=_NextPart_000_00DC_01CDED96.756E1B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno:

 

Thank you for feedback = on the support of the bits

 

Having lived through all = the revisions of BGP,=A0 it was also my recollection was that this was a = clarification. =A0John’s memory matched mine. =

 

The reason for an RFC = was to clearly draw a line when implementations engage in enforcing this = behavior.=A0 =A0Please also take a look at the idea of capabilities = signaling the specifics in error handling. =A0I’ll write-up the = draft on these issues.

 

On paragraph 3 and = habits - The discussion suggest I should consult =A0the bgp-issues = draft.=A0 During the RFC4271 creation we had a long email thread that = Andrew Lange captured in a document (bgp-issues).=A0 You may be able to = find an old copy of that draft.=A0 =A0=A0My recollection is that we = discussed habits.=A0 Let me review that text and get back to you. =

 

By the way, Stewart = Bryant asked for a reformatting of that bgp-issues into one or more of = the different forms (short review, web page, and a clean-up longer = version).=A0 =A0I’ll try to “hurry” along that rewrite = so we can review it together.

 

To clarify your = question:

 

“what is a propagation of an attribute vs a new = (re)origination. E.g. if the value is changed, is this a propagation or = an re-origination?”

 

John said: =

When a BGP speaker propagates = an attribute, it MUST propagate these flags as = received.

--------

 

I agree we = also need to clear up what’s a propagation or a re-origination.=A0 = Are there some changes that you have operational concerns about (e.g. = 2-byte/4byte AS changes, private AS stripping).

 

Sue = =A0

 

 

From:= = idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = bruno.decraene@orange.com
Sent: Tuesday, January 08, 2013 = 3:53 AM
To: Susan Hares; 'John G. Scudder'
Cc: idr = wg
Subject: Re: [Idr] 2 week WG adoption & LC on = draft-hares-idr-update-attrib-low-bits-fix-00.

 

Susan, = John,

 

I support this draft (WG = adoption & WG LC).

 

IMHO, it clarifies the = original meaning of RFC 4271. (i.e. "when sent" meant when = originated)

 

I’m not a big fan = of the current =A73. Known BGP Implementation = Habits

- I would propose to move it to = appendix.

- “Habits” sound strange to me. But = I’ll leave English language to others.

- IMHO the doc should = clarify which behavior/habit is compliant with this document and which = are not.

- From a protocol/IETF standpoint, do have a = consensus that this draft is merely a clarification i.e. we are not = changing the RFC 4271 spec? or not? If the former, those behaviors are = not “habits” but non compliant implementations. This = document is a clarification, so let’s be clear. If the latter, may = be the document should not call this a clarification but a = re-specification of those bits.

 

I also agree with Chris, = that we need to specify what is a propagation of an attribute vs a new = (re)origination. E.g. if the value is changed, is this a propagation or = an re-origination? I’m not sure I have an opinion on this. = Eventually the draft could allow both. E.g. “SHOULD be = propagated” (or re-originated, but a SHOULD rather than a = MUST).

 

 

There had been a = discussion about whether such clarification should be handled by a new = draft or by an errata. What’s the outcome / = rule?

 

Thanks,

Regards,

Bruno

 

From:= = idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Monday, January 07, 2013 = 8:31 PM
To: idr = wg
Cc: 'John G. Scudder'
Subject: [Idr] 2 week WG = adoption & LC on = draft-hares-idr-update-attrib-low-bits-fix-00.

 

 

Idr folks: =

 

May the new year = sparkle with joy for you-all.

 

Our discussion on = the lower-order four bits came to resolution

to clarify the RFC 4721 text. John and I decided the best way =

to make sure all = parties agree to the solution is to float

a mini-draft that summaries this editorial fix to = RFC4721.

 

Because the = mini-draft is so simple, we’re going to do a =

2 WG adoption and = LC call combined.  If anyone objects, = we’ll

drop back to just a = 2 week WG adoption. 

 

The draft name is: = 

 
 Update Attribute =
Flag Low Bits Clarification
 =
draft-hares-idr-update-attrib-low-bits-fix-00

 

gotten at = :

 

http://datatracker.ietf.org/doc/draft-hares-idr-update-attrib= -low-bits-fix/

 

 

Purpose is: =

 

  This draft = provides an update to RFC 4721 to clarify the use of = the

   = lower-order four bits of the Attribute flag in the Update = message.

 

Authors: John = Scudder and Sue Hares

 

Comment early and = often.

 

 

Sue Hares = and  John Scudder 

___________________________________________________________________=
______________________________________________________<=
/pre>
 
Ce message et ses =
pieces jointes peuvent contenir des informations confidentielles ou =
privilegiees et ne doivent donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le =
signaler
a l'expediteur et =
le detruire ainsi que les pieces jointes. Les messages electroniques =
etant susceptibles d'alteration,
France =
Telecom - Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
 
This message and =
its attachments may contain confidential or privileged information that =
may be protected by law;
they should not be =
distributed, used or copied without =
authorisation.
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be =
altered, France Telecom - Orange is not liable for messages that have =
been modified, changed or falsified.
Thank =
you.
------=_NextPart_000_00DC_01CDED96.756E1B80-- From rrice@broadcom.com Tue Jan 8 09:48:16 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467401F0CB3 for ; Tue, 8 Jan 2013 09:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao4W3sVr7rpb for ; Tue, 8 Jan 2013 09:48:13 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA4021F8548 for ; Tue, 8 Jan 2013 09:48:13 -0800 (PST) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 08 Jan 2013 09:44:54 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.17) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 8 Jan 2013 09:47:57 -0800 Received: from SJEXCHMB13.corp.ad.broadcom.com ( [fe80::9d40:1e86:a7dc:c46a]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 8 Jan 2013 09:47:57 -0800 From: "Rob (William) Rice" To: "Jakob Heitz" , "Brian Dickson" , "John Leslie" Thread-Topic: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: Ac3tDXDBNQ2m6YB3SR2ENK4IPDGzagASlPYAAAPQnwAAA/GOgAAOcJng Date: Tue, 8 Jan 2013 17:47:56 +0000 Message-ID: References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <2F3EBB88EC3A454AAB08915FBF0B8C7E152A60@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E152A60@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CF2849F3Q42377217-01-01 Content-Type: multipart/alternative; boundary=_000_DA52363A1FF16D46A4F6AD9836FB586604070E38SJEXCHMB13corpa_ Cc: idr wg , "John G. Scudder" , Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:48:16 -0000 --_000_DA52363A1FF16D46A4F6AD9836FB586604070E38SJEXCHMB13corpa_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I agree with Jakob. Given that implementations exist that don't propagate these bits today, if = you do update 4271, at what point would you be willing to define new flags = and trust that all routers would propagate them properly? Given the ambigui= ty of the wording in 4271, it seems safer to signal any new behavior within= the new attribute value. Rob From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jakob= Heitz Sent: Monday, January 07, 2013 7:05 PM To: Brian Dickson; John Leslie Cc: idr wg; Susan Hares; John G. Scudder Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. It's too late. Those bits are dead. There's plenty more bits in the sea. Even if your peer supports them, your peer's peer might not. Even for non-transitive attributes. The best we can do is set them to 0, so nothing breaks. -- Jakob Heitz. ________________________________ From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Brian= Dickson Sent: Monday, January 07, 2013 2:12 PM To: John Leslie Cc: idr wg; John G. Scudder; Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. I have an open question, primarily intended for the folks "experimenting" a= cross the Internet (and causing much excitement): If there is even the slightest possibility of using some of these bits in f= uture, REGARDLESS of for what, maybe the need to use them across unaware pa= rties could be signalled/negotiated? For example, a new Capability to be negotiated, call it DONT_MESS_WITH. If negotiated, the unambiguous behavior of "pass unchanged" applies to the = bits in question. In any other case, any presumption about the bits getting through should no= t be made, and the current "MUST BE ZERO" should apply to all. This would then mean, if NOT negotiated, allow any, but it is okay to stomp= on them (but not required!!). If the folks USING the bits really want to do more experiments and/or use t= hem, a quick I-D on the new Capability would be nice, and I would support i= t. While I would lean towards ALWAYS zeroing out the bits, I can see the argum= ent the other way, and am fine with the current draft in LC, regardless of = whether it is SHOULD or MUST. Brian On Mon, Jan 7, 2013 at 3:22 PM, John Leslie > wrote: Susan Hares > wrote: > > Our discussion on the lower-order four bits came to resolution > to clarify the RFC 4721 text. John and I decided the best way > to make sure all parties agree to the solution is to float > a mini-draft that summaries this editorial fix to RFC4721. > > Because the mini-draft is so simple, we're going to do a > 2 WG adoption and LC call combined. If anyone objects, we'll > drop back to just a 2 week WG adoption. > > The draft name is: > Update Attribute Flag Low Bits Clarification > draft-hares-idr-update-attrib-low-bits-fix-00 I think we will need to back off the "MUST propagate these flags as received". We are going to have, for a number of years, legacy equipment which resets these bits to zero when propagating: after all, it's 100% compliant with 4271 to do so. Also, I don't think we can be sure that some modification of these bits in propagation will never prove useful. I suggest changing that MUST to a SHOULD: " " The lower-order four bits of the Attribute Flags octet are " unused. They MUST be zero when originated. When received, any " value MUST be accepted. When a BGP speaker propagates an " attribute, it SHOULD propagate these flags as received. -- John Leslie > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_DA52363A1FF16D46A4F6AD9836FB586604070E38SJEXCHMB13corpa_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

I agree with Jakob.

 

Given that implementations e= xist that don’t propagate these bits today, if you do update 4271, at= what point would you be willing to define new flags and trust that all routers would propagate them properly? Given the ambiguity of the= wording in 4271, it seems safer to signal any new behavior within the new = attribute value.

 

Rob

 

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Monday, January 07, 2013 7:05 PM
To: Brian Dickson; John Leslie
Cc: idr wg; Susan Hares; John G. Scudder
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

 

It's too late. Those bits are dead. There'= s plenty more bits in the sea.

 

Even if your peer supports them, your peer= 's peer might not.

Even for non-transitive attributes.=

The best we can do is set them to 0, so no= thing breaks.

--
Jakob Heitz.

 

 

From:<= /span> idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Brian Dickson
Sent: Monday, January 07, 2013 2:12 PM
To: John Leslie
Cc: idr wg; John G. Scudder; Susan Hares
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

I have an open question, primarily intended for the = folks "experimenting" across the Internet (and causing much excit= ement):

 

If there is even the slightest possibility of using = some of these bits in future, REGARDLESS of for what, maybe the need to use= them across unaware parties could be signalled/negotiated?

 

For example, a new Capability to be negotiated, call= it DONT_MESS_WITH.

 

If negotiated, the unambiguous behavior of "pas= s unchanged" applies to the bits in question.

 

In any other case, any presumption about the bits ge= tting through should not be made, and the current "MUST BE ZERO" = should apply to all.

 

This would then mean, if NOT negotiated, allow any, = but it is okay to stomp on them (but not required!!).

 

If the folks USING the bits really want to do more e= xperiments and/or use them, a quick I-D on the new Capability would be nice= , and I would support it.

 

While I would lean towards ALWAYS zeroing out the bi= ts, I can see the argument the other way, and am fine with the current draf= t in LC, regardless of whether it is SHOULD or MUST.

 

Brian

On Mon, Jan 7, 2013 at 3:22 PM, John Leslie <john@jlc.net> wrote:

Susan Hares <shares@ndzh.com> wrote:
>
> Our discussion on the lower-order four bits came to resolution
> to clarify the RFC 4721 text. John and I decided the best way
> to make sure all parties agree to the solution is to float
> a mini-draft that summaries this editorial fix to RFC4721.
>
> Because the mini-draft is so simple, we're going to do a
> 2 WG adoption and LC call combined.  If anyone objects, we'll
> drop back to just a 2 week WG adoption.
>
> The draft name is:
>  Update Attribute Flag Low Bits Clarification
>  draft-hares-idr-update-attrib-low-bits-fix-00

   I think we will need to back off the &q= uot;MUST propagate these flags
as received".

   We are going to have, for a number of years, legacy equipment<= br> which resets these bits to zero when propagating: after all, it's
100% compliant with 4271 to do so. Also, I don't think we can be
sure that some modification of these bits in propagation will never
prove useful.

   I suggest changing that MUST to a SHOULD:
"
" The lower-order four bits of the Attribute Flags octet are
" unused.  They MUST be zero when originated.  When received= , any
" value MUST be accepted.  When a BGP speaker propagates an
" attribute, it SHOULD propagate these flags as received.

--
John Leslie <john@jlc.net>
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

--_000_DA52363A1FF16D46A4F6AD9836FB586604070E38SJEXCHMB13corpa_-- From bruno.decraene@orange.com Tue Jan 8 09:54:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608B211E80FB for ; Tue, 8 Jan 2013 09:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njn5g99J1cQW for ; Tue, 8 Jan 2013 09:54:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9779511E80E5 for ; Tue, 8 Jan 2013 09:54:12 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id C03AD3B4115; Tue, 8 Jan 2013 18:54:11 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 903634C0D9; Tue, 8 Jan 2013 18:54:11 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 18:54:11 +0100 From: To: Susan Hares , "'John G. Scudder'" Thread-Topic: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: AQFBMhac0XhAnKoHOyYB3aId+E7wFgKYokvUmUROTUCAAAou8A== Date: Tue, 8 Jan 2013 17:54:10 +0000 Message-ID: <13876_1357667651_50EC5D43_13876_777_1_53C29892C857584299CBF5D05346208A122E70@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <25434_1357635185_50EBDE71_25434_13095_3_53C29892C857584299CBF5D05346208A1229AD@PEXCVZYM11.corporate.adroot.infra.ftgroup> <00db01cdedc0$5e41b280$1ac51780$@ndzh.com> In-Reply-To: <00db01cdedc0$5e41b280$1ac51780$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A122E70PEXCVZYM11corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:54:18 -0000 --_000_53C29892C857584299CBF5D05346208A122E70PEXCVZYM11corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Susan, Thanks for your answer. >From: Susan Hares [mailto:shares@ndzh.com] > I agree we also need to clear up what's a propagation or a re-origination= . Are there some changes that you have operational concerns about (e.g. 2-= byte/4byte AS changes, private AS stripping). Not that I can think of. A priori, I was rather on the side of a clear and simple rule being totally= unspecific: nothing specific on a per attribute basis, nor specific to the= reason for changing the value of that attribute (including the handling of= 2 different attributes(2-byte/4 byte) for the same data (as path). For exa= mple "propagation is re-advertising the attribute unchanged, as received. A= nything else is re-origination" or the opposite POV: "Origination is adding= a new non existing attribute to the route. Anything else is propagation" Attributes which are a set of multiple values are tricky. e.g. when adding = a community value in the community attribute: - if I reset the bits, we lose the end to end propagation of the bits for t= he received communities - if I keep the bits, I advertise my new community with specific bits that = I may not be aware of their consequences. Bruno From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, January 08, 2013 5:51 PM To: DECRAENE Bruno OLNC/OLN; 'John G. Scudder' Cc: 'idr wg' Subject: RE: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. Bruno: Thank you for feedback on the support of the bits Having lived through all the revisions of BGP, it was also my recollection= was that this was a clarification. John's memory matched mine. The reason for an RFC was to clearly draw a line when implementations engag= e in enforcing this behavior. Please also take a look at the idea of capa= bilities signaling the specifics in error handling. I'll write-up the draf= t on these issues. On paragraph 3 and habits - The discussion suggest I should consult the bg= p-issues draft. During the RFC4271 creation we had a long email thread tha= t Andrew Lange captured in a document (bgp-issues). You may be able to fin= d an old copy of that draft. My recollection is that we discussed habits= . Let me review that text and get back to you. By the way, Stewart Bryant asked for a reformatting of that bgp-issues into= one or more of the different forms (short review, web page, and a clean-up= longer version). I'll try to "hurry" along that rewrite so we can review= it together. To clarify your question: "what is a propagation of an attribute vs a new (re)origination. E.g. if th= e value is changed, is this a propagation or an re-origination?" John said: When a BGP speaker propagates an attribute, it MUST propagate these flags a= s received. -------- I agree we also need to clear up what's a propagation or a re-origination. = Are there some changes that you have operational concerns about (e.g. 2-by= te/4byte AS changes, private AS stripping). Sue From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of bruno.decraene@orange.com Sent: Tuesday, January 08, 2013 3:53 AM To: Susan Hares; 'John G. Scudder' Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. Susan, John, I support this draft (WG adoption & WG LC). IMHO, it clarifies the original meaning of RFC 4271. (i.e. "when sent" mean= t when originated) I'm not a big fan of the current =A73. Known BGP Implementation Habits - I would propose to move it to appendix. - "Habits" sound strange to me. But I'll leave English language to others. - IMHO the doc should clarify which behavior/habit is compliant with this d= ocument and which are not. - From a protocol/IETF standpoint, do have a consensus that this draft is m= erely a clarification i.e. we are not changing the RFC 4271 spec? or not? I= f the former, those behaviors are not "habits" but non compliant implementa= tions. This document is a clarification, so let's be clear. If the latter, = may be the document should not call this a clarification but a re-specifica= tion of those bits. I also agree with Chris, that we need to specify what is a propagation of a= n attribute vs a new (re)origination. E.g. if the value is changed, is this= a propagation or an re-origination? I'm not sure I have an opinion on this= . Eventually the draft could allow both. E.g. "SHOULD be propagated" (or re= -originated, but a SHOULD rather than a MUST). There had been a discussion about whether such clarification should be hand= led by a new draft or by an errata. What's the outcome / rule? Thanks, Regards, Bruno From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Susan Hares Sent: Monday, January 07, 2013 8:31 PM To: idr wg Cc: 'John G. Scudder' Subject: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low= -bits-fix-00. Idr folks: May the new year sparkle with joy for you-all. Our discussion on the lower-order four bits came to resolution to clarify the RFC 4721 text. John and I decided the best way to make sure all parties agree to the solution is to float a mini-draft that summaries this editorial fix to RFC4721. Because the mini-draft is so simple, we're going to do a 2 WG adoption and LC call combined. If anyone objects, we'll drop back to just a 2 week WG adoption. The draft name is: Update Attribute Flag Low Bits Clarification draft-hares-idr-update-attrib-low-bits-fix-00 gotten at : http://datatracker.ietf.org/doc/draft-hares-idr-update-attrib-low-bits-fix/ Purpose is: This draft provides an update to RFC 4721 to clarify the use of the lower-order four bits of the Attribute flag in the Update message. Authors: John Scudder and Sue Hares Comment early and often. Sue Hares and John Scudder ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A122E70PEXCVZYM11corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Susan,

 

Thanks for your answer= .

 

>From: Susan Hares [mailto:shares@ndzh.com]
> I agree we also need to clear up what̵= 7;s a propagation or a re-origination.  Are there some changes that yo= u have operational concerns about (e.g. 2-byte/4byte AS changes, private AS= stripping).

&n= bsp;

Not tha= t I can think of.

A prior= i, I was rather on the side of a clear and simple rule being totally unspecific: nothing specific on a per attribute basis, nor specific = to the reason for changing the value of that attribute (including the handl= ing of 2 different attributes(2-byte/4 byte) for the same data (as path). F= or example “propagation is re-advertising the attribute unchanged, as received. Anything else is re-origination̶= 1; or the opposite POV: “Origination is adding a new non existing att= ribute to the route. Anything else is propagation”<= /p>

&n= bsp;

Attribu= tes which are a set of multiple values are tricky. e.g. when adding a commu= nity value in the community attribute:

- if I = reset the bits, we lose the end to end propagation of the bits for the rece= ived communities

- if I = keep the bits, I advertise my new community with specific bits that I may n= ot be aware of their consequences.

Bruno

&n= bsp;

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Tuesday, January 08, 2013 5:51 PM
To: DECRAENE Bruno OLNC/OLN; 'John G. Scudder'
Cc: 'idr wg'
Subject: RE: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

 

Bruno:<= o:p>

&n= bsp;

Thank y= ou for feedback on the support of the bits

&n= bsp;

Having = lived through all the revisions of BGP,  it was also my recollection w= as that this was a clarification.  John’s memory matched mine.

&n= bsp;

The rea= son for an RFC was to clearly draw a line when implementations engage in en= forcing this behavior.   Please also take a look at the idea of c= apabilities signaling the specifics in error handling.  I’ll write-up the draft on these issues.

&n= bsp;

On para= graph 3 and habits - The discussion suggest I should consult  the bgp-= issues draft.  During the RFC4271 creation we had a long email thread = that Andrew Lange captured in a document (bgp-issues).  You may be able to find an old copy of that draft.    My re= collection is that we discussed habits.  Let me review that text and g= et back to you.

&n= bsp;

By the = way, Stewart Bryant asked for a reformatting of that bgp-issues into one or= more of the different forms (short review, web page, and a clean-up longer= version).   I’ll try to “hurry” along that rewrite so we can review it together.

&n= bsp;

To clar= ify your question:

&n= bsp;

“= what is a propagation of an attribute vs a new (re)origination. E.g. if the= value is changed, is this a propagation or an re-origination?”<= /o:p>

&n= bsp;

John sa= id:

When a BGP speaker propagates a= n attribute, it MUST propagate these flags as received.

--------

 

I agree we also need to clear u= p what’s a propagation or a re-origination.  Are there some chan= ges that you have operational concerns about (e.g. 2-byte/4byte AS changes,= private AS stripping).

 

Sue  

&n= bsp;

&n= bsp;

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Tuesday, January 08, 2013 3:53 AM
To: Susan Hares; 'John G. Scudder'
Cc: idr wg
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

 

Susan, = John,

&n= bsp;

I suppo= rt this draft (WG adoption & WG LC).

&n= bsp;

IMHO, i= t clarifies the original meaning of RFC 4271. (i.e. "when sent" m= eant when originated)

&n= bsp;

I’= ;m not a big fan of the current =A73. Known BGP Implementation Habits<= /o:p>

- I wou= ld propose to move it to appendix.

- ̶= 0;Habits” sound strange to me. But I’ll leave English language = to others.

- IMHO = the doc should clarify which behavior/habit is compliant with this document= and which are not.

- From = a protocol/IETF standpoint, do have a consensus that this draft is merely a= clarification i.e. we are not changing the RFC 4271 spec? or not? If the f= ormer, those behaviors are not “habits” but non compliant implementations. This document is a clarification, so le= t’s be clear. If the latter, may be the document should not call this= a clarification but a re-specification of those bits.

&n= bsp;

I also = agree with Chris, that we need to specify what is a propagation of an attri= bute vs a new (re)origination. E.g. if the value is changed, is this a prop= agation or an re-origination? I’m not sure I have an opinion on this. Eventually the draft could allow both. E.g= . “SHOULD be propagated” (or re-originated, but a SHOULD rather= than a MUST).

&n= bsp;

&n= bsp;

There h= ad been a discussion about whether such clarification should be handled by = a new draft or by an errata. What’s the outcome / rule?

&n= bsp;

Thanks,=

Regards= ,

Bruno

&n= bsp;

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, January 07, 2013 8:31 PM
To: idr wg
Cc: 'John G. Scudder'
Subject: [Idr] 2 week WG adoption & LC on draft-hares-idr-update= -attrib-low-bits-fix-00.

 

 

Idr folks:

 

May the new year sparkle with joy for you-a= ll.

 

Our discussion on the lower-order four bits= came to resolution

to clarify the RFC 4721 text. John and I de= cided the best way

to make sure all parties agree to the solut= ion is to float

a mini-draft that summaries this editorial = fix to RFC4721.

 

Because the mini-draft is so simple, weR= 17;re going to do a

2 WG adoption and LC call combined.  I= f anyone objects, we’ll

drop back to just a 2 week WG adoption.&nbs= p;

 

The draft name is: 

 
 Update Attribute Flag Low Bits Clarification
 draft-hares-idr-update-attrib-low-bits-fix-00

 

gotten at :

 

http://datatracker.ietf.org/do= c/draft-hares-idr-update-attrib-low-bits-fix/

 

 

Purpose is:

 

  This draft provides an update to RFC= 4721 to clarify the use of the

   lower-order four bits of the A= ttribute flag in the Update message.

 

Authors: John Scudder and Sue Hares

 

Comment early and often.<= /p>

 

 

Sue Hares and  John Scudde= r 

_=
___________________________________________________________________________=
_____________________________________________
<=
o:p> 
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler
a=
 l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
F=
rance Telecom - Orange decline toute responsabilite si ce message a ete alt=
ere, deforme ou falsifie. Merci.
<=
o:p> 
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, France Telecom - Orange is not liable for messages=
 that have been modified, changed or falsified.
T=
hank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A122E70PEXCVZYM11corpora_-- From bruno.decraene@orange.com Tue Jan 8 10:10:17 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CE91F0CF5 for ; Tue, 8 Jan 2013 10:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCKTX1vgb9RN for ; Tue, 8 Jan 2013 10:10:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DB3F81F0CB3 for ; Tue, 8 Jan 2013 10:10:12 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 21E78264652; Tue, 8 Jan 2013 19:10:11 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D8DD54C0E7; Tue, 8 Jan 2013 19:10:10 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 19:10:10 +0100 From: To: "Rob (William) Rice" , Jakob Heitz , Brian Dickson , John Leslie Thread-Topic: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: Ac3tDXDBNQ2m6YB3SR2ENK4IPDGzagASlPYAAAPQnwAAA/GOgAAOcJngAAYtcgA= Date: Tue, 8 Jan 2013 18:10:09 +0000 Message-ID: <13871_1357668611_50EC6102_13871_88_1_53C29892C857584299CBF5D05346208A122E9E@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <2F3EBB88EC3A454AAB08915FBF0B8C7E152A60@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A122E9EPEXCVZYM11corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: idr wg , Susan Hares , "John G. Scudder" Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 18:10:17 -0000 --_000_53C29892C857584299CBF5D05346208A122E9EPEXCVZYM11corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > It's too late. Those bits are dead. I don't see how this is different from deprecating/retiring and reusing a c= ode point. Is there an existing IETF way for this? http://tools.ietf.org/ht= ml/draft-kompella-mpls-special-purpose-labels-01#section-3.2 is discussing = this in the MPLS WG. Should this be a topic for next routing area meeting? I'm not sure why this would be too late. Some time may be needed before (re= )using them but I don't see why this should stop us from deprecating existi= ng "use" (actually existing non use/mess). > at what point would you be willing to define new flags and trust that all= routers would propagate them properly? I don't know but it looks like an issue for the one willing to reuse those = bits, not for the ones deprecating/clearing its current use. From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rob (= William) Rice Sent: Tuesday, January 08, 2013 6:48 PM To: Jakob Heitz; Brian Dickson; John Leslie Cc: idr wg; John G. Scudder; Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. I agree with Jakob. Given that implementations exist that don't propagate these bits today, if = you do update 4271, at what point would you be willing to define new flags = and trust that all routers would propagate them properly? Given the ambigui= ty of the wording in 4271, it seems safer to signal any new behavior within= the new attribute value. Rob From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Jakob Heitz Sent: Monday, January 07, 2013 7:05 PM To: Brian Dickson; John Leslie Cc: idr wg; Susan Hares; John G. Scudder Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. It's too late. Those bits are dead. There's plenty more bits in the sea. Even if your peer supports them, your peer's peer might not. Even for non-transitive attributes. The best we can do is set them to 0, so nothing breaks. -- Jakob Heitz. ________________________________ From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Brian Dickson Sent: Monday, January 07, 2013 2:12 PM To: John Leslie Cc: idr wg; John G. Scudder; Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. I have an open question, primarily intended for the folks "experimenting" a= cross the Internet (and causing much excitement): If there is even the slightest possibility of using some of these bits in f= uture, REGARDLESS of for what, maybe the need to use them across unaware pa= rties could be signalled/negotiated? For example, a new Capability to be negotiated, call it DONT_MESS_WITH. If negotiated, the unambiguous behavior of "pass unchanged" applies to the = bits in question. In any other case, any presumption about the bits getting through should no= t be made, and the current "MUST BE ZERO" should apply to all. This would then mean, if NOT negotiated, allow any, but it is okay to stomp= on them (but not required!!). If the folks USING the bits really want to do more experiments and/or use t= hem, a quick I-D on the new Capability would be nice, and I would support i= t. While I would lean towards ALWAYS zeroing out the bits, I can see the argum= ent the other way, and am fine with the current draft in LC, regardless of = whether it is SHOULD or MUST. Brian On Mon, Jan 7, 2013 at 3:22 PM, John Leslie > wrote: Susan Hares > wrote: > > Our discussion on the lower-order four bits came to resolution > to clarify the RFC 4721 text. John and I decided the best way > to make sure all parties agree to the solution is to float > a mini-draft that summaries this editorial fix to RFC4721. > > Because the mini-draft is so simple, we're going to do a > 2 WG adoption and LC call combined. If anyone objects, we'll > drop back to just a 2 week WG adoption. > > The draft name is: > Update Attribute Flag Low Bits Clarification > draft-hares-idr-update-attrib-low-bits-fix-00 I think we will need to back off the "MUST propagate these flags as received". We are going to have, for a number of years, legacy equipment which resets these bits to zero when propagating: after all, it's 100% compliant with 4271 to do so. Also, I don't think we can be sure that some modification of these bits in propagation will never prove useful. I suggest changing that MUST to a SHOULD: " " The lower-order four bits of the Attribute Flags octet are " unused. They MUST be zero when originated. When received, any " value MUST be accepted. When a BGP speaker propagates an " attribute, it SHOULD propagate these flags as received. -- John Leslie > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A122E9EPEXCVZYM11corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> It's too late. Those bits are dead.<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif";color:#1F497D">

 = ;

I don̵= 7;t see how this is different from deprecating/retiring and reusing a code = point. Is there an existing IETF way for this? http://tools.ietf.org/html/draft-kompella-mpls-special-purpose-labels-01#se= ction-3.2 is discussing this in the MPLS WG. Should this be a topic for= next routing area meeting?

 = ;

I’m = not sure why this would be too late. Some time may be needed before (re)usi= ng them but I don’t see why this should stop us from deprecating existing “use” (actually existing non use/mess).

 = ;

> at what = point would you be willing to define new flags and trust that all routers w= ould propagate them properly?

I don̵= 7;t know but it looks like an issue for the one willing to reuse those bits= , not for the ones deprecating/clearing its current use.<= /p>

 = ;

 = ;

 = ;

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rob (William) Rice
Sent: Tuesday, January 08, 2013 6:48 PM
To: Jakob Heitz; Brian Dickson; John Leslie
Cc: idr wg; John G. Scudder; Susan Hares
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

 

I agree with = Jakob.

 

Given that im= plementations exist that don’t propagate these bits today, if you do = update 4271, at what point would you be willing to define new flags and trust that all routers would propagate them properly? Given the ambigu= ity of the wording in 4271, it seems safer to signal any new behavior withi= n the new attribute value.

 

Rob

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Monday, January 07, 2013 7:05 PM
To: Brian Dickson; John Leslie
Cc: idr wg; Susan Hares; John G. Scudder
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

 

It's too late. Those bits a= re dead. There's plenty more bits in the sea.

 

Even if your peer supports = them, your peer's peer might not.

Even for non-transitive att= ributes.

The best we can do is set t= hem to 0, so nothing breaks.<= /p>

--
Jakob Heitz.

 

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Brian Dickson
Sent: Monday, January 07, 2013 2:12 PM
To: John Leslie
Cc: idr wg; John G. Scudder; Susan Hares
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.<= /p>

I have an open question, primar= ily intended for the folks "experimenting" across the Internet (a= nd causing much excitement):

 

If there is even the slightest = possibility of using some of these bits in future, REGARDLESS of for what, = maybe the need to use them across unaware parties could be signalled/negoti= ated?

 

For example, a new Capability t= o be negotiated, call it DONT_MESS_WITH.

 

If negotiated, the unambiguous = behavior of "pass unchanged" applies to the bits in question.

 

In any other case, any presumpt= ion about the bits getting through should not be made, and the current &quo= t;MUST BE ZERO" should apply to all.

 

This would then mean, if NOT ne= gotiated, allow any, but it is okay to stomp on them (but not required!!).<= o:p>

 

If the folks USING the bits rea= lly want to do more experiments and/or use them, a quick I-D on the new Cap= ability would be nice, and I would support it.

 

While I would lean towards ALWA= YS zeroing out the bits, I can see the argument the other way, and am fine = with the current draft in LC, regardless of whether it is SHOULD or MUST.

 

= Brian

On Mon, Jan 7, 2013 at 3:22 PM,= John Leslie <john@jlc= .net> wrote:

= Susan Hares <shares@ndzh.com> = wrote:
>
> Our discussion on the lower-order four bits came to resolution
> to clarify the RFC 4721 text. John and I decided the best way
> to make sure all parties agree to the solution is to float
> a mini-draft that summaries this editorial fix to RFC4721.
>
> Because the mini-draft is so simple, we're going to do a
> 2 WG adoption and LC call combined.  If anyone objects, we'll
> drop back to just a 2 week WG adoption.
>
> The draft name is:
>  Update Attribute Flag Low Bits Clarification
>  draft-hares-idr-update-attrib-low-bits-fix-00<= /p>

   I think we will ne= ed to back off the "MUST propagate these flags
as received".

   We are going to have, for a number of years, legacy equipment<= br> which resets these bits to zero when propagating: after all, it's
100% compliant with 4271 to do so. Also, I don't think we can be
sure that some modification of these bits in propagation will never
prove useful.

   I suggest changing that MUST to a SHOULD:
"
" The lower-order four bits of the Attribute Flags octet are
" unused.  They MUST be zero when originated.  When received= , any
" value MUST be accepted.  When a BGP speaker propagates an
" attribute, it SHOULD propagate these flags as received.

--
John Leslie <john@jlc.net>
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A122E9EPEXCVZYM11corpora_-- From jakob.heitz@ericsson.com Tue Jan 8 10:26:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B1911E80E2 for ; Tue, 8 Jan 2013 10:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pS++6fjYuYi for ; Tue, 8 Jan 2013 10:26:34 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 124E921F869A for ; Tue, 8 Jan 2013 10:26:33 -0800 (PST) Received: from EUSAAHC008.ericsson.se ([147.117.188.96]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r08IetDW021921; Tue, 8 Jan 2013 12:40:59 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 13:25:27 -0500 From: Jakob Heitz To: "bruno.decraene@orange.com" Thread-Topic: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: AQHN7chTyHF9urtbW0SrJKQPwy+Q6JhADwqA//+wdS0= Date: Tue, 8 Jan 2013 18:25:27 +0000 Message-ID: References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <2F3EBB88EC3A454AAB08915FBF0B8C7E152A60@eusaamb109.ericsson.se> , <13871_1357668611_50EC6102_13871_88_1_53C29892C857584299CBF5D05346208A122E9E@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <13871_1357668611_50EC6102_13871_88_1_53C29892C857584299CBF5D05346208A122E9E@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F37A1592E58B451DB7FFDD19E7CB7B23ericssoncom_" MIME-Version: 1.0 Cc: idr wg , "John G. Scudder" , John Leslie , Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 18:26:36 -0000 --_000_F37A1592E58B451DB7FFDD19E7CB7B23ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The only thing I will do is ignore on receipt and set to 0 on send. Anything else risks causing a session reset. It's not worth it. -- Jakob Heitz. On Jan 8, 2013, at 10:10 AM, "bruno.decraene@orange.com" > wrote: > It's too late. Those bits are dead. I don=92t see how this is different from deprecating/retiring and reusing a= code point. Is there an existing IETF way for this? http://tools.ietf.org/= html/draft-kompella-mpls-special-purpose-labels-01#section-3.2 is discussin= g this in the MPLS WG. Should this be a topic for next routing area meeting= ? I=92m not sure why this would be too late. Some time may be needed before (= re)using them but I don=92t see why this should stop us from deprecating ex= isting =93use=94 (actually existing non use/mess). > at what point would you be willing to define new flags and trust that all= routers would propagate them properly? I don=92t know but it looks like an issue for the one willing to reuse thos= e bits, not for the ones deprecating/clearing its current use. From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Rob (William) Rice Sent: Tuesday, January 08, 2013 6:48 PM To: Jakob Heitz; Brian Dickson; John Leslie Cc: idr wg; John G. Scudder; Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. I agree with Jakob. Given that implementations exist that don=92t propagate these bits today, i= f you do update 4271, at what point would you be willing to define new flag= s and trust that all routers would propagate them properly? Given the ambig= uity of the wording in 4271, it seems safer to signal any new behavior with= in the new attribute value. Rob From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Jakob Heitz Sent: Monday, January 07, 2013 7:05 PM To: Brian Dickson; John Leslie Cc: idr wg; Susan Hares; John G. Scudder Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. It's too late. Those bits are dead. There's plenty more bits in the sea. Even if your peer supports them, your peer's peer might not. Even for non-transitive attributes. The best we can do is set them to 0, so nothing breaks. -- Jakob Heitz. ________________________________ From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Brian Dickson Sent: Monday, January 07, 2013 2:12 PM To: John Leslie Cc: idr wg; John G. Scudder; Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib= -low-bits-fix-00. I have an open question, primarily intended for the folks "experimenting" a= cross the Internet (and causing much excitement): If there is even the slightest possibility of using some of these bits in f= uture, REGARDLESS of for what, maybe the need to use them across unaware pa= rties could be signalled/negotiated? For example, a new Capability to be negotiated, call it DONT_MESS_WITH. If negotiated, the unambiguous behavior of "pass unchanged" applies to the = bits in question. In any other case, any presumption about the bits getting through should no= t be made, and the current "MUST BE ZERO" should apply to all. This would then mean, if NOT negotiated, allow any, but it is okay to stomp= on them (but not required!!). If the folks USING the bits really want to do more experiments and/or use t= hem, a quick I-D on the new Capability would be nice, and I would support i= t. While I would lean towards ALWAYS zeroing out the bits, I can see the argum= ent the other way, and am fine with the current draft in LC, regardless of = whether it is SHOULD or MUST. Brian On Mon, Jan 7, 2013 at 3:22 PM, John Leslie > wrote: Susan Hares > wrote: > > Our discussion on the lower-order four bits came to resolution > to clarify the RFC 4721 text. John and I decided the best way > to make sure all parties agree to the solution is to float > a mini-draft that summaries this editorial fix to RFC4721. > > Because the mini-draft is so simple, we're going to do a > 2 WG adoption and LC call combined. If anyone objects, we'll > drop back to just a 2 week WG adoption. > > The draft name is: > Update Attribute Flag Low Bits Clarification > draft-hares-idr-update-attrib-low-bits-fix-00 I think we will need to back off the "MUST propagate these flags as received". We are going to have, for a number of years, legacy equipment which resets these bits to zero when propagating: after all, it's 100% compliant with 4271 to do so. Also, I don't think we can be sure that some modification of these bits in propagation will never prove useful. I suggest changing that MUST to a SHOULD: " " The lower-order four bits of the Attribute Flags octet are " unused. They MUST be zero when originated. When received, any " value MUST be accepted. When a BGP speaker propagates an " attribute, it SHOULD propagate these flags as received. -- John Leslie > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_F37A1592E58B451DB7FFDD19E7CB7B23ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The only thing I will do is ignore on receipt and set to 0 on send.
Anything else risks causing a session reset. It's not worth it.

--
Jakob Heitz.


On Jan 8, 2013, at 10:10 AM, "bruno.decraene@orange.com" <bruno.decraene@orange.com> wrote:

> It's too late. Those bits are dead.<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif";color:#1F497D">

 = ;

I don=92t = see how this is different from deprecating/retiring and reusing a code poin= t. Is there an existing IETF way for this? http://tools.ietf.org/html/draft-kompella-mpls-special-purpose-labels-01#se= ction-3.2 is discussing this in the MPLS WG. Should this be a topic for= next routing area meeting?

 = ;

I=92m not = sure why this would be too late. Some time may be needed before (re)using t= hem but I don=92t see why this should stop us from deprecating existing =93use=94 (actually existing non use/mess).

 = ;

> at what = point would you be willing to define new flags and trust that all routers w= ould propagate them properly?

I don=92t = know but it looks like an issue for the one willing to reuse those bits, no= t for the ones deprecating/clearing its current use.

 = ;

 = ;

 = ;

From: idr-bounces@ietf.org [mailto:id= r-bounces@ietf.org] On Behalf Of Rob (William) Rice
Sent: Tuesday, January 08, 2013 6:48 PM
To: Jakob Heitz; Brian Dickson; John Leslie
Cc: idr wg; John G. Scudder; Susan Hares
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

 

I agree with = Jakob.

 

Given that im= plementations exist that don=92t propagate these bits today, if you do upda= te 4271, at what point would you be willing to define new flags and trust that all routers would propagate them properly? Given the ambigu= ity of the wording in 4271, it seems safer to signal any new behavior withi= n the new attribute value.

 

Rob

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
Sent: Monday, January 07, 2013 7:05 PM
To: Brian Dickson; John Leslie
Cc: idr wg; Susan Hares; John G. Scudder
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.

 

It's too late. Those bits a= re dead. There's plenty more bits in the sea.

 

Even if your peer supports = them, your peer's peer might not.

Even for non-transitive att= ributes.

The best we can do is set t= hem to 0, so nothing breaks.<= /p>

--
Jakob Heitz.

 

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Brian Dickson
Sent: Monday, January 07, 2013 2:12 PM
To: John Leslie
Cc: idr wg; John G. Scudder; Susan Hares
Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-up= date-attrib-low-bits-fix-00.<= /p>

I have an open question, primar= ily intended for the folks "experimenting" across the Internet (a= nd causing much excitement):

 

If there is even the slightest = possibility of using some of these bits in future, REGARDLESS of for what, = maybe the need to use them across unaware parties could be signalled/negoti= ated?

 

For example, a new Capability t= o be negotiated, call it DONT_MESS_WITH.

 

If negotiated, the unambiguous = behavior of "pass unchanged" applies to the bits in question.

 

In any other case, any presumpt= ion about the bits getting through should not be made, and the current &quo= t;MUST BE ZERO" should apply to all.

 

This would then mean, if NOT ne= gotiated, allow any, but it is okay to stomp on them (but not required!!).<= o:p>

 

If the folks USING the bits rea= lly want to do more experiments and/or use them, a quick I-D on the new Cap= ability would be nice, and I would support it.

 

While I would lean towards ALWA= YS zeroing out the bits, I can see the argument the other way, and am fine = with the current draft in LC, regardless of whether it is SHOULD or MUST.

 

= Brian

On Mon, Jan 7, 2013 at 3:22 PM,= John Leslie <john@jlc= .net> wrote:

= Susan Hares <shares@ndzh.com> = wrote:
>
> Our discussion on the lower-order four bits came to resolution
> to clarify the RFC 4721 text. John and I decided the best way
> to make sure all parties agree to the solution is to float
> a mini-draft that summaries this editorial fix to RFC4721.
>
> Because the mini-draft is so simple, we're going to do a
> 2 WG adoption and LC call combined.  If anyone objects, we'll
> drop back to just a 2 week WG adoption.
>
> The draft name is:
>  Update Attribute Flag Low Bits Clarification
>  draft-hares-idr-update-attrib-low-bits-fix-00<= /p>

   I think we will ne= ed to back off the "MUST propagate these flags
as received".

   We are going to have, for a number of years, legacy equipment<= br> which resets these bits to zero when propagating: after all, it's
100% compliant with 4271 to do so. Also, I don't think we can be
sure that some modification of these bits in propagation will never
prove useful.

   I suggest changing that MUST to a SHOULD:
"
" The lower-order four bits of the Attribute Flags octet are
" unused.  They MUST be zero when originated.  When received= , any
" value MUST be accepted.  When a BGP speaker propagates an
" attribute, it SHOULD propagate these flags as received.

--
John Leslie <john@jlc.net>
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_F37A1592E58B451DB7FFDD19E7CB7B23ericssoncom_-- From farmer@umn.edu Tue Jan 8 11:44:33 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C28611E80A5 for ; Tue, 8 Jan 2013 11:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqEEDJRm-pDC for ; Tue, 8 Jan 2013 11:44:32 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6D18D11E80A2 for ; Tue, 8 Jan 2013 11:44:32 -0800 (PST) Received: from mail-ie0-f199.google.com (mail-ie0-f199.google.com [209.85.223.199]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 8 Jan 2013 13:44:14 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f199.google.com [209.85.223.199] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f199.google.com with SMTP id k10so4303529iea.2 for ; Tue, 08 Jan 2013 11:44:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=5s0kfej15p91XnlnXjVhDj//eVY5KJbQdF5bK54lFws=; b=e1sl1YmYDFlZGIn6Tv+k8SRtO0V4g/sOeceWkXslBRNtPoX1j5mlv0h7W1hyOBLz98 4JQRFnqNOq3wmMJDKDbvwa9dAPAGghSHhpyYwUr4d5L5aokFt6oLm6VvmuHIE6xgjb5Q 5P9aAtlvLabeZlJKjyG/LR4G6cr/b9B2tRxYYrT8SKJ3az/PDH3vJXu35OhstBzhqDHe j95j3UcXNqTkOJiU2PO52ha9Kn7ob7N4kfbE18GC6DLuxXA4l/QMc10a0tfE7JKMycYq Px2foFAkJTDBTH9HqckxFm2t6sFOfQ4GuTILQtMTIjupayWxalLs/cI/u6VwZuPhUqnb fZFw== X-Received: by 10.50.242.73 with SMTP id wo9mr9952494igc.36.1357674254813; Tue, 08 Jan 2013 11:44:14 -0800 (PST) X-Received: by 10.50.242.73 with SMTP id wo9mr9952486igc.36.1357674254696; Tue, 08 Jan 2013 11:44:14 -0800 (PST) Received: from x-134-84-88-28.nts.umn.edu ([2607:ea00:101:2001:507f:26b5:4674:9eaf]) by mx.google.com with ESMTPS id b13sm310461igp.7.2013.01.08.11.44.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Jan 2013 11:44:14 -0800 (PST) Message-ID: <50EC770C.40603@umn.edu> Date: Tue, 08 Jan 2013 13:44:12 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "t.petch" References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> In-Reply-To: <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlA2cPZMbUV8p258UpIfIDoo8x8ZJBhJlem1s6hQKuAQr8FySGDvt4BNQaRqCWGqEC8Fb3U/J5dUGVz4Wu5msrc85CkWbqoy8oSTTjfZMTovS6xgbG9p+LWb8amIFc8f8D4bCS5 Cc: "'John G. Scudder'" , idr wg , John Leslie , Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 19:44:33 -0000 On 1/8/13 09:39 , t.petch wrote: > ----- Original Message ----- > From: "John Leslie" > To: "Susan Hares" > Cc: "idr wg" ; "'John G. Scudder'" > Sent: Monday, January 07, 2013 8:22 PM >> Susan Hares wrote: >>> >>> Our discussion on the lower-order four bits came to resolution >>> to clarify the RFC 4721 text. John and I decided the best way >>> to make sure all parties agree to the solution is to float >>> a mini-draft that summaries this editorial fix to RFC4721. >>> >>> Because the mini-draft is so simple, we're going to do a >>> 2 WG adoption and LC call combined. If anyone objects, we'll >>> drop back to just a 2 week WG adoption. >>> >>> The draft name is: >>> Update Attribute Flag Low Bits Clarification >>> draft-hares-idr-update-attrib-low-bits-fix-00 >> >> I think we will need to back off the "MUST propagate these flags >> as received". >> >> We are going to have, for a number of years, legacy equipment >> which resets these bits to zero when propagating: after all, it's >> 100% compliant with 4271 to do so. Also, I don't think we can be >> sure that some modification of these bits in propagation will never >> prove useful. >> >> I suggest changing that MUST to a SHOULD: >> " >> " The lower-order four bits of the Attribute Flags octet are >> " unused. They MUST be zero when originated. When received, any >> " value MUST be accepted. When a BGP speaker propagates an >> " attribute, it SHOULD propagate these flags as received. > > Since we have two different ways of interpreting the current spec, any > nailing down of the spec is going to make some implementations > non-conforming; that is unavoidable. > > Looking to the future, the underlying question is whether or not > we want to use the bits as optional transitive. > > If we do, then they should be propagated as received and we can > have a progressive deployment of a new use. > > If we do not, then they should be propagated as zero and we cannot > used them until all involved parties have been updated to understand > them. > > So both approaches are right, depending on future use, and I do not > know which is the right 'right' answer. SHOULD is a bit of a weasel > word here, allowing some fence sitting. > > It seems a bit like fail-danger and fail-safe, more psychology than > technology. I agree we need to pick one approach or the other, and it should be either "MUST propagate as received", or "MUST propagate as zero". The SHOULD option is essentially what we have now and really won't fix the issue one way or the other. If we want to go the SHOULD route, I'd prefer we just add "When received, any value MUST be accepted" as a simple errata. I prefer the "MUST propagate as received" option personally. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jakob.heitz@ericsson.com Tue Jan 8 11:52:03 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DF321F8464 for ; Tue, 8 Jan 2013 11:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+WpmEtuEwc8 for ; Tue, 8 Jan 2013 11:52:02 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id BE12C21F8456 for ; Tue, 8 Jan 2013 11:52:02 -0800 (PST) Received: from EUSAAHC003.ericsson.se ([147.117.188.81]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id r08JpqbT026209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jan 2013 13:51:56 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 14:51:55 -0500 From: Jakob Heitz To: David Farmer Thread-Topic: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: AQHN7bbP1u4CkFFzzE67CQEI//46/ZhAKXQA//+uVnQ= Date: Tue, 8 Jan 2013 19:51:54 +0000 Message-ID: <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net>, <50EC770C.40603@umn.edu> In-Reply-To: <50EC770C.40603@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , Susan Hares , "John G. Scudder" , John Leslie Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 19:52:03 -0000 > I agree we need to pick one approach or the other, and it should be eithe= r "MUST propagate as received", or "MUST propagate as zero". The SHOULD op= tion is essentially what we have now and really won't fix the issue one way= or the other. If we want to go the SHOULD route, I'd prefer we just add = "When received, any value MUST be accepted" as a simple errata. >=20 > I prefer the "MUST propagate as received" option personally. That would work if bgp were new. But it's not. Anything other than "MUST propagate as zero" risks a session reset. I won't= do that. -- Jakob Heitz.= From susan.hares@huawei.com Tue Jan 8 20:23:49 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D461F0CF6 for ; Tue, 8 Jan 2013 20:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKL8QuzPYKY6 for ; Tue, 8 Jan 2013 20:23:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E25871F0C5F for ; Tue, 8 Jan 2013 20:23:40 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOO36294; Wed, 09 Jan 2013 04:23:36 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 Jan 2013 04:22:03 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 Jan 2013 04:23:00 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.124]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 8 Jan 2013 20:22:55 -0800 From: Susan Hares To: "idr@ietf.org" Thread-Topic: Mail failure Thread-Index: Ac3uIP7SFN0RCrziSpeOnqH99EV83w== Date: Wed, 9 Jan 2013 04:22:55 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B146237C8EDB@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.111] Content-Type: multipart/alternative; boundary="_000_728F9B956B2C48439CA9294B1723B146237C8EDBdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Idr] Mail failure X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 04:23:49 -0000 --_000_728F9B956B2C48439CA9294B1723B146237C8EDBdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all: I have a mail failure on share@ndzh.com. Unfortunat= ely, it will be toss mail for the next 12 hours. Send mail to susan.hares= @hauwei.com in the interim. If you wish the sad tale drop me a private line. It has all the makings = of a movie - big corporations buying up little companies, broken software, = clueless mom & pop co-lo service , clueful people leaving companies, a mid= night transfer to a new service company and ... much more. Sue PS - yes the ndzh.com domain is owned by my husband and I. --_000_728F9B956B2C48439CA9294B1723B146237C8EDBdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all:

 

I have a mail failure on share@ndzh.com.  Unfortunately, it will be toss mail for th= e next 12 hours.   Send mail to susan.hares@hauwei.com in the= interim. 

 

If you wish the sad tale drop me a private line. &nb= sp;  It has all the makings of a movie – big corporations b= uying up little companies, broken software, clueless mom & pop co-lo se= rvice , clueful people leaving companies,  a midnight transfer to a new service company and … much more.

 

Sue

 

PS – yes the ndzh.com domain is owned by my hu= sband and I.

--_000_728F9B956B2C48439CA9294B1723B146237C8EDBdfweml509mbxchi_-- From bruno.decraene@orange.com Wed Jan 9 06:06:07 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F04721F86CB for ; Wed, 9 Jan 2013 06:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9sQaF8PX4Wr for ; Wed, 9 Jan 2013 06:06:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B57EA21F85D2 for ; Wed, 9 Jan 2013 06:06:04 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 18C653B45A0; Wed, 9 Jan 2013 15:06:04 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id B637B27C127; Wed, 9 Jan 2013 15:06:03 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Wed, 9 Jan 2013 15:05:15 +0100 From: To: Jakob Heitz Thread-Topic: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: AQHN7chTNQ2m6YB3SR2ENK4IPDGzaphADwqA//+wdS2AAT6ZwA== Date: Wed, 9 Jan 2013 14:05:14 +0000 Message-ID: <21480_1357740363_50ED794B_21480_415_1_53C29892C857584299CBF5D05346208A1233C0@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <2F3EBB88EC3A454AAB08915FBF0B8C7E152A60@eusaamb109.ericsson.se> , <13871_1357668611_50EC6102_13871_88_1_53C29892C857584299CBF5D05346208A122E9E@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1233C0PEXCVZYM11corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: idr wg , Susan Hares , "John G. Scudder" Subject: Re: [Idr] 2 week WG adoption & LC on draft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 14:06:07 -0000 --_000_53C29892C857584299CBF5D05346208A1233C0PEXCVZYM11corpora_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGUgb25seSB0aGluZyBJIHdpbGwgZG8gaXMgaWdub3JlIG9uIHJlY2VpcHQgYW5kIHNldCB0 byAwIG9uIHNlbmQuDQoNCkkgdGhpbmsgSSB1bmRlcnN0YW5kIHlvdXIgcG9pbnQgZnJvbSBhbiBp bXBsZW1lbnRhdGlvbi9wcm9kdWN0IHBvaW50IG9mIHZpZXcuICh5ZXQsIEnigJltIHdvbmRlcmlu ZyBpZiB5b3UgYWxzbyBjaGFuZ2VkIHlvdXIgaW1wbGVtZW50YXRpb24gdG8gYWNjb21tb2RhdGUg b3RoZXJzIGJ1Z3MuIEUuZy4gZXJyb3JzIG9uIHRoZSBleHRlbmRlZCBsZW5ndGggYml0LiBBbmQg SU1ITyB0aGUgZ29vZCBhbnN3ZXIgaXMgcmF0aGVyIHRvIGFsbG93IHRoZSBTUCB0byBmaWx0ZXIg b3V0IGFuIHVwZGF0ZS9hdHRyaWJ1dGUgYmFzZWQgb24gYW55IGRhdGEgaW4gdGhlIHVwZGF0ZSBt ZXNzYWdlIChpbmNsdWRpbmcgdW51c2VkIGZpZWxkIGFzIHdlIHNlZSkuDQoNCg0KDQpIb3dldmVy LCBmcm9tIGEgc3RhbmRhcmRpemF0aW9uIHN0YW5kcG9pbnQsIElNTyB3ZSBzaG91bGQgbm90IGNo YW5nZS9kZWZpbmUgc3RhbmRhcmQgYmFzZWQgb24gYnVncyBpbiBvbmUgaW1wbGVtZW50YXRpb24u DQoNCkJlY2F1c2UgaWYgd2UgcmVmZXIgdG8gdGhlIHNhbWUgaXNzdWUg4oCcUmVjZXB0aW9uIG9m IGEgc2V0IGJpdCBpbiB0aGUgbG93ZXLiiJJvcmRlciBmb3VyIGJpdHMgb2YgdGhlIEF0dHJpYnV0 ZSBGbGFncyBvY3RldCBpbiBhIEJHUCB1cGRhdGUgd2lsbCBjYXVzZSB0aGUgQkdQIHNlc3Npb24g dG8gcmVzZXQu4oCdLCB0aGlzIGlzIGEgYnVnIGFuZCBSRkMgNDI3MSB3YXMgY3J5c3RhbCBjbGVh ciBvbiB0aGlzIHBvaW50IOKAnE1VU1QgYmUgaWdub3JlZCB3aGVuIHJlY2VpdmVk4oCdLg0KDQpT byBJIHN0aWxsIHN1cHBvcnQgV0cgYWRvcHRpb24gYmVjYXVzZSBJIGJlbGlldmUgc3BlYyBjbGFy aXR5IGlzIGEgZ29vZCB0aGluZy4NCg0KDQoNClRoYXQgYmVpbmcgc2FpZCwgeW91IGhhdmUgYSBw b2ludCBvbiBkZXBsb3ltZW50LiBTbyBnaXZlbiB0aGF0Og0KDQphKSBtb3JlIHdvcmsgaXMgbmVl ZGVkIG9uIHRoZSBkcmFmdCB0byBjbGFyaWZ5IHRoZSBhY3Rpb24vZGVmaW5pdGlvbiBvZiBhbiBh dHRyaWJ1dGUgcHJvcGFnYXRpb24NCg0KYikgSURSIHBvbGljeSByZXF1ZXN0IDIgaW1wbGVtZW50 YXRpb25zIG9mIGRyYWZ0IGluIG9yZGVyIHRvIGF2b2lkIHBvdGVudGlhbCByaXNrIGluIGRlcGxv eW1lbnRzIGluIGEgY3JpdGljYWwgaW5mcmFzdHJ1Y3R1cmUsIHdoaWxlIGhlcmUgdGhlcmUgaXMg YSBrbm93biByaXNrIHdoZW4gZGVwbG95aW5nLg0KDQoNCg0KSSBub3cgdGVuZCB0byBiZWxpZXZl IHRoYXQgdGhpcyBkcmFmdCBpcyBub3QgeWV0IHJlYWR5IGZvciBSRkMgcHVibGljYXRpb24uIEhl bmNlIEkgd2l0aGRyYXcgbXkgc3VwcG9ydCBmb3IgV0cgTEMgdW50aWwgdGhlIHRlY2huaWNhbCBw b2ludCAoYSkgaXMgY2xhcmlmaWVkIGFuZCB0aGF0IHdlIGJlbGlldmUgZGVwbG95ZWQgYnVnZ3kg dmVyc2lvbnMgaGF2ZSBiZWVuIHJlcGxhY2VkIChvciB3aGF0ZXZlciBydWxlIHRoZSBJRVRGL1dH IGhhcyBmb3IgY29kZSBwb2ludCByZXVzZSkuDQoNCg0KDQpCcnVubw0KDQoNCg0KRnJvbTogSmFr b2IgSGVpdHogW21haWx0bzpqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb21dDQpTZW50OiBUdWVzZGF5 LCBKYW51YXJ5IDA4LCAyMDEzIDc6MjUgUE0NClRvOiBERUNSQUVORSBCcnVubyBPTE5DL09MTg0K Q2M6IFJvYiAoV2lsbGlhbSkgUmljZTsgQnJpYW4gRGlja3NvbjsgSm9obiBMZXNsaWU7IGlkciB3 ZzsgSm9obiBHLiBTY3VkZGVyOyBTdXNhbiBIYXJlcw0KU3ViamVjdDogUmU6IFtJZHJdIDIgd2Vl ayBXRyBhZG9wdGlvbiAmIExDIG9uIGRyYWZ0LWhhcmVzLWlkci11cGRhdGUtYXR0cmliLWxvdy1i aXRzLWZpeC0wMC4NCg0KVGhlIG9ubHkgdGhpbmcgSSB3aWxsIGRvIGlzIGlnbm9yZSBvbiByZWNl aXB0IGFuZCBzZXQgdG8gMCBvbiBzZW5kLg0KQW55dGhpbmcgZWxzZSByaXNrcyBjYXVzaW5nIGEg c2Vzc2lvbiByZXNldC4gSXQncyBub3Qgd29ydGggaXQuDQoNCi0tDQpKYWtvYiBIZWl0ei4NCg0K DQpPbiBKYW4gOCwgMjAxMywgYXQgMTA6MTAgQU0sICJicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29t PG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPiIgPGJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+PiB3cm90ZToNCj4gSXQncyB0 b28gbGF0ZS4gVGhvc2UgYml0cyBhcmUgZGVhZC4NCg0KSSBkb27igJl0IHNlZSBob3cgdGhpcyBp cyBkaWZmZXJlbnQgZnJvbSBkZXByZWNhdGluZy9yZXRpcmluZyBhbmQgcmV1c2luZyBhIGNvZGUg cG9pbnQuIElzIHRoZXJlIGFuIGV4aXN0aW5nIElFVEYgd2F5IGZvciB0aGlzPyBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rb21wZWxsYS1tcGxzLXNwZWNpYWwtcHVycG9zZS1sYWJl bHMtMDEjc2VjdGlvbi0zLjIgaXMgZGlzY3Vzc2luZyB0aGlzIGluIHRoZSBNUExTIFdHLiBTaG91 bGQgdGhpcyBiZSBhIHRvcGljIGZvciBuZXh0IHJvdXRpbmcgYXJlYSBtZWV0aW5nPw0KDQpJ4oCZ bSBub3Qgc3VyZSB3aHkgdGhpcyB3b3VsZCBiZSB0b28gbGF0ZS4gU29tZSB0aW1lIG1heSBiZSBu ZWVkZWQgYmVmb3JlIChyZSl1c2luZyB0aGVtIGJ1dCBJIGRvbuKAmXQgc2VlIHdoeSB0aGlzIHNo b3VsZCBzdG9wIHVzIGZyb20gZGVwcmVjYXRpbmcgZXhpc3Rpbmcg4oCcdXNl4oCdIChhY3R1YWxs eSBleGlzdGluZyBub24gdXNlL21lc3MpLg0KDQo+IGF0IHdoYXQgcG9pbnQgd291bGQgeW91IGJl IHdpbGxpbmcgdG8gZGVmaW5lIG5ldyBmbGFncyBhbmQgdHJ1c3QgdGhhdCBhbGwgcm91dGVycyB3 b3VsZCBwcm9wYWdhdGUgdGhlbSBwcm9wZXJseT8NCkkgZG9u4oCZdCBrbm93IGJ1dCBpdCBsb29r cyBsaWtlIGFuIGlzc3VlIGZvciB0aGUgb25lIHdpbGxpbmcgdG8gcmV1c2UgdGhvc2UgYml0cywg bm90IGZvciB0aGUgb25lcyBkZXByZWNhdGluZy9jbGVhcmluZyBpdHMgY3VycmVudCB1c2UuDQoN Cg0KDQpGcm9tOiBpZHItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5v cmc+IFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2IgKFdpbGxp YW0pIFJpY2UNClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMDgsIDIwMTMgNjo0OCBQTQ0KVG86IEph a29iIEhlaXR6OyBCcmlhbiBEaWNrc29uOyBKb2huIExlc2xpZQ0KQ2M6IGlkciB3ZzsgSm9obiBH LiBTY3VkZGVyOyBTdXNhbiBIYXJlcw0KU3ViamVjdDogUmU6IFtJZHJdIDIgd2VlayBXRyBhZG9w dGlvbiAmIExDIG9uIGRyYWZ0LWhhcmVzLWlkci11cGRhdGUtYXR0cmliLWxvdy1iaXRzLWZpeC0w MC4NCg0KSSBhZ3JlZSB3aXRoIEpha29iLg0KDQpHaXZlbiB0aGF0IGltcGxlbWVudGF0aW9ucyBl eGlzdCB0aGF0IGRvbuKAmXQgcHJvcGFnYXRlIHRoZXNlIGJpdHMgdG9kYXksIGlmIHlvdSBkbyB1 cGRhdGUgNDI3MSwgYXQgd2hhdCBwb2ludCB3b3VsZCB5b3UgYmUgd2lsbGluZyB0byBkZWZpbmUg bmV3IGZsYWdzIGFuZCB0cnVzdCB0aGF0IGFsbCByb3V0ZXJzIHdvdWxkIHByb3BhZ2F0ZSB0aGVt IHByb3Blcmx5PyBHaXZlbiB0aGUgYW1iaWd1aXR5IG9mIHRoZSB3b3JkaW5nIGluIDQyNzEsIGl0 IHNlZW1zIHNhZmVyIHRvIHNpZ25hbCBhbnkgbmV3IGJlaGF2aW9yIHdpdGhpbiB0aGUgbmV3IGF0 dHJpYnV0ZSB2YWx1ZS4NCg0KUm9iDQoNCkZyb206IGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzppZHItYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEpha29iIEhlaXR6DQpTZW50OiBNb25kYXksIEphbnVhcnkgMDcsIDIwMTMgNzow NSBQTQ0KVG86IEJyaWFuIERpY2tzb247IEpvaG4gTGVzbGllDQpDYzogaWRyIHdnOyBTdXNhbiBI YXJlczsgSm9obiBHLiBTY3VkZGVyDQpTdWJqZWN0OiBSZTogW0lkcl0gMiB3ZWVrIFdHIGFkb3B0 aW9uICYgTEMgb24gZHJhZnQtaGFyZXMtaWRyLXVwZGF0ZS1hdHRyaWItbG93LWJpdHMtZml4LTAw Lg0KDQpJdCdzIHRvbyBsYXRlLiBUaG9zZSBiaXRzIGFyZSBkZWFkLiBUaGVyZSdzIHBsZW50eSBt b3JlIGJpdHMgaW4gdGhlIHNlYS4NCg0KRXZlbiBpZiB5b3VyIHBlZXIgc3VwcG9ydHMgdGhlbSwg eW91ciBwZWVyJ3MgcGVlciBtaWdodCBub3QuDQpFdmVuIGZvciBub24tdHJhbnNpdGl2ZSBhdHRy aWJ1dGVzLg0KVGhlIGJlc3Qgd2UgY2FuIGRvIGlzIHNldCB0aGVtIHRvIDAsIHNvIG5vdGhpbmcg YnJlYWtzLg0KDQotLQ0KSmFrb2IgSGVpdHouDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb206IGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0Bp ZXRmLm9yZz4gW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFu IERpY2tzb24NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAwNywgMjAxMyAyOjEyIFBNDQpUbzogSm9o biBMZXNsaWUNCkNjOiBpZHIgd2c7IEpvaG4gRy4gU2N1ZGRlcjsgU3VzYW4gSGFyZXMNClN1Ympl Y3Q6IFJlOiBbSWRyXSAyIHdlZWsgV0cgYWRvcHRpb24gJiBMQyBvbiBkcmFmdC1oYXJlcy1pZHIt dXBkYXRlLWF0dHJpYi1sb3ctYml0cy1maXgtMDAuDQpJIGhhdmUgYW4gb3BlbiBxdWVzdGlvbiwg cHJpbWFyaWx5IGludGVuZGVkIGZvciB0aGUgZm9sa3MgImV4cGVyaW1lbnRpbmciIGFjcm9zcyB0 aGUgSW50ZXJuZXQgKGFuZCBjYXVzaW5nIG11Y2ggZXhjaXRlbWVudCk6DQoNCklmIHRoZXJlIGlz IGV2ZW4gdGhlIHNsaWdodGVzdCBwb3NzaWJpbGl0eSBvZiB1c2luZyBzb21lIG9mIHRoZXNlIGJp dHMgaW4gZnV0dXJlLCBSRUdBUkRMRVNTIG9mIGZvciB3aGF0LCBtYXliZSB0aGUgbmVlZCB0byB1 c2UgdGhlbSBhY3Jvc3MgdW5hd2FyZSBwYXJ0aWVzIGNvdWxkIGJlIHNpZ25hbGxlZC9uZWdvdGlh dGVkPw0KDQpGb3IgZXhhbXBsZSwgYSBuZXcgQ2FwYWJpbGl0eSB0byBiZSBuZWdvdGlhdGVkLCBj YWxsIGl0IERPTlRfTUVTU19XSVRILg0KDQpJZiBuZWdvdGlhdGVkLCB0aGUgdW5hbWJpZ3VvdXMg YmVoYXZpb3Igb2YgInBhc3MgdW5jaGFuZ2VkIiBhcHBsaWVzIHRvIHRoZSBiaXRzIGluIHF1ZXN0 aW9uLg0KDQpJbiBhbnkgb3RoZXIgY2FzZSwgYW55IHByZXN1bXB0aW9uIGFib3V0IHRoZSBiaXRz IGdldHRpbmcgdGhyb3VnaCBzaG91bGQgbm90IGJlIG1hZGUsIGFuZCB0aGUgY3VycmVudCAiTVVT VCBCRSBaRVJPIiBzaG91bGQgYXBwbHkgdG8gYWxsLg0KDQpUaGlzIHdvdWxkIHRoZW4gbWVhbiwg aWYgTk9UIG5lZ290aWF0ZWQsIGFsbG93IGFueSwgYnV0IGl0IGlzIG9rYXkgdG8gc3RvbXAgb24g dGhlbSAoYnV0IG5vdCByZXF1aXJlZCEhKS4NCg0KSWYgdGhlIGZvbGtzIFVTSU5HIHRoZSBiaXRz IHJlYWxseSB3YW50IHRvIGRvIG1vcmUgZXhwZXJpbWVudHMgYW5kL29yIHVzZSB0aGVtLCBhIHF1 aWNrIEktRCBvbiB0aGUgbmV3IENhcGFiaWxpdHkgd291bGQgYmUgbmljZSwgYW5kIEkgd291bGQg c3VwcG9ydCBpdC4NCg0KV2hpbGUgSSB3b3VsZCBsZWFuIHRvd2FyZHMgQUxXQVlTIHplcm9pbmcg b3V0IHRoZSBiaXRzLCBJIGNhbiBzZWUgdGhlIGFyZ3VtZW50IHRoZSBvdGhlciB3YXksIGFuZCBh bSBmaW5lIHdpdGggdGhlIGN1cnJlbnQgZHJhZnQgaW4gTEMsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhl ciBpdCBpcyBTSE9VTEQgb3IgTVVTVC4NCg0KQnJpYW4NCk9uIE1vbiwgSmFuIDcsIDIwMTMgYXQg MzoyMiBQTSwgSm9obiBMZXNsaWUgPGpvaG5AamxjLm5ldDxtYWlsdG86am9obkBqbGMubmV0Pj4g d3JvdGU6DQpTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5j b20+PiB3cm90ZToNCj4NCj4gT3VyIGRpc2N1c3Npb24gb24gdGhlIGxvd2VyLW9yZGVyIGZvdXIg Yml0cyBjYW1lIHRvIHJlc29sdXRpb24NCj4gdG8gY2xhcmlmeSB0aGUgUkZDIDQ3MjEgdGV4dC4g Sm9obiBhbmQgSSBkZWNpZGVkIHRoZSBiZXN0IHdheQ0KPiB0byBtYWtlIHN1cmUgYWxsIHBhcnRp ZXMgYWdyZWUgdG8gdGhlIHNvbHV0aW9uIGlzIHRvIGZsb2F0DQo+IGEgbWluaS1kcmFmdCB0aGF0 IHN1bW1hcmllcyB0aGlzIGVkaXRvcmlhbCBmaXggdG8gUkZDNDcyMS4NCj4NCj4gQmVjYXVzZSB0 aGUgbWluaS1kcmFmdCBpcyBzbyBzaW1wbGUsIHdlJ3JlIGdvaW5nIHRvIGRvIGENCj4gMiBXRyBh ZG9wdGlvbiBhbmQgTEMgY2FsbCBjb21iaW5lZC4gIElmIGFueW9uZSBvYmplY3RzLCB3ZSdsbA0K PiBkcm9wIGJhY2sgdG8ganVzdCBhIDIgd2VlayBXRyBhZG9wdGlvbi4NCj4NCj4gVGhlIGRyYWZ0 IG5hbWUgaXM6DQo+ICBVcGRhdGUgQXR0cmlidXRlIEZsYWcgTG93IEJpdHMgQ2xhcmlmaWNhdGlv bg0KPiAgZHJhZnQtaGFyZXMtaWRyLXVwZGF0ZS1hdHRyaWItbG93LWJpdHMtZml4LTAwDQogICBJ IHRoaW5rIHdlIHdpbGwgbmVlZCB0byBiYWNrIG9mZiB0aGUgIk1VU1QgcHJvcGFnYXRlIHRoZXNl IGZsYWdzDQphcyByZWNlaXZlZCIuDQoNCiAgIFdlIGFyZSBnb2luZyB0byBoYXZlLCBmb3IgYSBu dW1iZXIgb2YgeWVhcnMsIGxlZ2FjeSBlcXVpcG1lbnQNCndoaWNoIHJlc2V0cyB0aGVzZSBiaXRz IHRvIHplcm8gd2hlbiBwcm9wYWdhdGluZzogYWZ0ZXIgYWxsLCBpdCdzDQoxMDAlIGNvbXBsaWFu dCB3aXRoIDQyNzEgdG8gZG8gc28uIEFsc28sIEkgZG9uJ3QgdGhpbmsgd2UgY2FuIGJlDQpzdXJl IHRoYXQgc29tZSBtb2RpZmljYXRpb24gb2YgdGhlc2UgYml0cyBpbiBwcm9wYWdhdGlvbiB3aWxs IG5ldmVyDQpwcm92ZSB1c2VmdWwuDQoNCiAgIEkgc3VnZ2VzdCBjaGFuZ2luZyB0aGF0IE1VU1Qg dG8gYSBTSE9VTEQ6DQoiDQoiIFRoZSBsb3dlci1vcmRlciBmb3VyIGJpdHMgb2YgdGhlIEF0dHJp YnV0ZSBGbGFncyBvY3RldCBhcmUNCiIgdW51c2VkLiAgVGhleSBNVVNUIGJlIHplcm8gd2hlbiBv cmlnaW5hdGVkLiAgV2hlbiByZWNlaXZlZCwgYW55DQoiIHZhbHVlIE1VU1QgYmUgYWNjZXB0ZWQu ICBXaGVuIGEgQkdQIHNwZWFrZXIgcHJvcGFnYXRlcyBhbg0KIiBhdHRyaWJ1dGUsIGl0IFNIT1VM RCBwcm9wYWdhdGUgdGhlc2UgZmxhZ3MgYXMgcmVjZWl2ZWQuDQoNCi0tDQpKb2huIExlc2xpZSA8 am9obkBqbGMubmV0PG1haWx0bzpqb2huQGpsYy5uZXQ+Pg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9y ZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZHINCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KRnJh bmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0K DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVj b20gLSBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sCkZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxl Y29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_53C29892C857584299CBF5D05346208A1233C0PEXCVZYM11corpora_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTHVjaWRhIENvbnNvbGUiOw0KCXBhbm9z ZS0xOjIgMTEgNiA5IDQgNSA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkJv b2sgQW50aXF1YSI7DQoJcGFub3NlLTE6MiA0IDYgMiA1IDMgNSAzIDMgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUg ZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQm9vayBBbnRpcXVhIiwic2VyaWYiOw0KCWNvbG9yOmJsdWU7DQoJZm9udC13ZWlnaHQ6 bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uUHJm b3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhU TUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBUaGUgb25seSB0aGluZyBJIHdpbGwgZG8gaXMgaWdub3Jl IG9uIHJlY2VpcHQgYW5kIHNldCB0byAwIG9uIHNlbmQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgdGhpbmsgSSB1bmRlcnN0YW5kIHlvdXIgcG9pbnQgZnJvbSBhbiBpbXBs ZW1lbnRhdGlvbi9wcm9kdWN0IHBvaW50IG9mIHZpZXcuICh5ZXQsIEnigJltIHdvbmRlcmluZyBp ZiB5b3UgYWxzbyBjaGFuZ2VkIHlvdXIgaW1wbGVtZW50YXRpb24gdG8gYWNjb21tb2RhdGUNCiBv dGhlcnMgYnVncy4gRS5nLiBlcnJvcnMgb24gdGhlIGV4dGVuZGVkIGxlbmd0aCBiaXQuIEFuZCBJ TUhPIHRoZSBnb29kIGFuc3dlciBpcyByYXRoZXIgdG8gYWxsb3cgdGhlIFNQIHRvIGZpbHRlciBv dXQgYW4gdXBkYXRlL2F0dHJpYnV0ZSBiYXNlZCBvbiBhbnkgZGF0YSBpbiB0aGUgdXBkYXRlIG1l c3NhZ2UgKGluY2x1ZGluZyB1bnVzZWQgZmllbGQgYXMgd2Ugc2VlKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwg ZnJvbSBhIHN0YW5kYXJkaXphdGlvbiBzdGFuZHBvaW50LCBJTU8gd2Ugc2hvdWxkIG5vdCBjaGFu Z2UvZGVmaW5lIHN0YW5kYXJkIGJhc2VkIG9uIGJ1Z3MgaW4gb25lIGltcGxlbWVudGF0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlY2F1c2UgaWYgd2UgcmVmZXIgdG8gdGhlIHNh bWUgaXNzdWUg4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5SZWNlcHRpb24gb2YgYSBzZXQgYml0IGluIHRoZSBsb3dlcuKIkm9yZGVyIGZvdXIgYml0 cyBvZiB0aGUgQXR0cmlidXRlIEZsYWdzIG9jdGV0IGluIGEgQkdQIHVwZGF0ZSB3aWxsIGNhdXNl IHRoZSBCR1Agc2Vzc2lvbiB0byByZXNldC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJ0sIHRoaXMgaXMgYSBidWcgYW5kIFJG QyA0MjcxIHdhcyBjcnlzdGFsIGNsZWFyIG9uIHRoaXMgcG9pbnQg4oCcPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj5NVVNUIGJlIGlnbm9yZWQgd2hlbiByZWNlaXZlZOKAnS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBJIHN0aWxsIHN1cHBvcnQgV0cgYWRvcHRpb24gYmVj YXVzZSBJIGJlbGlldmUgc3BlYyBjbGFyaXR5IGlzIGEgZ29vZCB0aGluZy48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGF0 IGJlaW5nIHNhaWQsIHlvdSBoYXZlIGEgcG9pbnQgb24gZGVwbG95bWVudC4gU28gZ2l2ZW4gdGhh dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hKSBtb3JlIHdvcmsgaXMgbmVlZGVkIG9u IHRoZSBkcmFmdCB0byBjbGFyaWZ5IHRoZSBhY3Rpb24vZGVmaW5pdGlvbiBvZiBhbiBhdHRyaWJ1 dGUgcHJvcGFnYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5iKSBJRFIgcG9saWN5 IHJlcXVlc3QgMiBpbXBsZW1lbnRhdGlvbnMgb2YgZHJhZnQgaW4gb3JkZXIgdG8gYXZvaWQgcG90 ZW50aWFsIHJpc2sgaW4gZGVwbG95bWVudHMgaW4gYSBjcml0aWNhbCBpbmZyYXN0cnVjdHVyZSwg d2hpbGUgaGVyZSB0aGVyZSBpcyBhIGtub3duIHJpc2sgd2hlbiBkZXBsb3lpbmcuPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSBub3cgdGVuZCB0byBiZWxpZXZlIHRoYXQgdGhpcyBkcmFmdCBpcyBub3QgeWV0IHJlYWR5IGZv ciBSRkMgcHVibGljYXRpb24uIEhlbmNlIEkgd2l0aGRyYXcgbXkgc3VwcG9ydCBmb3IgV0cgTEMg dW50aWwgdGhlIHRlY2huaWNhbCBwb2ludCAoYSkgaXMgY2xhcmlmaWVkIGFuZCB0aGF0IHdlIGJl bGlldmUgZGVwbG95ZWQgYnVnZ3kgdmVyc2lvbnMgaGF2ZSBiZWVuIHJlcGxhY2VkIChvciB3aGF0 ZXZlciBydWxlIHRoZSBJRVRGL1dHIGhhcyBmb3IgY29kZSBwb2ludCByZXVzZSkuPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ QnJ1bm88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmFrb2IgSGVpdHogW21haWx0bzpqYWtvYi5oZWl0ekBlcmlj c3Nvbi5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAwOCwgMjAxMyA3 OjI1IFBNPGJyPg0KPGI+VG86PC9iPiBERUNSQUVORSBCcnVubyBPTE5DL09MTjxicj4NCjxiPkNj OjwvYj4gUm9iIChXaWxsaWFtKSBSaWNlOyBCcmlhbiBEaWNrc29uOyBKb2huIExlc2xpZTsgaWRy IHdnOyBKb2huIEcuIFNjdWRkZXI7IFN1c2FuIEhhcmVzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbSWRyXSAyIHdlZWsgV0cgYWRvcHRpb24gJmFtcDsgTEMgb24gZHJhZnQtaGFyZXMtaWRyLXVw ZGF0ZS1hdHRyaWItbG93LWJpdHMtZml4LTAwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBv bmx5IHRoaW5nIEkgd2lsbCBkbyBpcyBpZ25vcmUgb24gcmVjZWlwdCBhbmQgc2V0IHRvIDAgb24g c2VuZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFueXRoaW5nIGVsc2Ugcmlza3MgY2F1c2luZyBhIHNlc3Npb24gcmVzZXQuIEl0J3Mgbm90IHdv cnRoIGl0Ljxicj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkpha29iIEhlaXR6LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KT24gSmFuIDgsIDIwMTMsIGF0IDEwOjEwIEFNLCAmcXVvdDs8YSBocmVmPSJtYWlsdG86 YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ow0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEg Q29uc29sZSZxdW90Oztjb2xvcjpwdXJwbGUiPkl0J3MgdG9vIGxhdGUuIFRob3NlIGJpdHMgYXJl IGRlYWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCBzZWUg aG93IHRoaXMgaXMgZGlmZmVyZW50IGZyb20gZGVwcmVjYXRpbmcvcmV0aXJpbmcgYW5kIHJldXNp bmcgYSBjb2RlIHBvaW50LiBJcyB0aGVyZSBhbiBleGlzdGluZyBJRVRGIHdheSBmb3IgdGhpcz8N CjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtvbXBlbGxhLW1wbHMt c3BlY2lhbC1wdXJwb3NlLWxhYmVscy0wMSNzZWN0aW9uLTMuMiI+DQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1rb21wZWxsYS1tcGxzLXNwZWNpYWwtcHVycG9zZS1sYWJlbHMtMDEj c2VjdGlvbi0zLjI8L2E+IGlzIGRpc2N1c3NpbmcgdGhpcyBpbiB0aGUgTVBMUyBXRy4gU2hvdWxk IHRoaXMgYmUgYSB0b3BpYyBmb3IgbmV4dCByb3V0aW5nIGFyZWEgbWVldGluZz88L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gbm90IHN1cmUgd2h5IHRoaXMgd291bGQg YmUgdG9vIGxhdGUuIFNvbWUgdGltZSBtYXkgYmUgbmVlZGVkIGJlZm9yZSAocmUpdXNpbmcgdGhl bSBidXQgSSBkb27igJl0IHNlZSB3aHkgdGhpcyBzaG91bGQgc3RvcCB1cyBmcm9tIGRlcHJlY2F0 aW5nDQogZXhpc3Rpbmcg4oCcdXNl4oCdIChhY3R1YWxseSBleGlzdGluZyBub24gdXNlL21lc3Mp Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mZ3Q7IGF0IHdoYXQgcG9pbnQgd291 bGQgeW91IGJlIHdpbGxpbmcgdG8gZGVmaW5lIG5ldyBmbGFncyBhbmQgdHJ1c3QgdGhhdCBhbGwg cm91dGVycyB3b3VsZCBwcm9wYWdhdGUgdGhlbSBwcm9wZXJseT88L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCBrbm93IGJ1dCBpdCBsb29rcyBsaWtl IGFuIGlzc3VlIGZvciB0aGUgb25lIHdpbGxpbmcgdG8gcmV1c2UgdGhvc2UgYml0cywgbm90IGZv ciB0aGUgb25lcyBkZXByZWNhdGluZy9jbGVhcmluZyBpdHMgY3VycmVudCB1c2UuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPg0KPGEgaHJlZj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0Bp ZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv Omlkci1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iIChXaWxs aWFtKSBSaWNlPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMDgsIDIwMTMgNjo0 OCBQTTxicj4NCjxiPlRvOjwvYj4gSmFrb2IgSGVpdHo7IEJyaWFuIERpY2tzb247IEpvaG4gTGVz bGllPGJyPg0KPGI+Q2M6PC9iPiBpZHIgd2c7IEpvaG4gRy4gU2N1ZGRlcjsgU3VzYW4gSGFyZXM8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIDIgd2VlayBXRyBhZG9wdGlvbiAmYW1wOyBM QyBvbiBkcmFmdC1oYXJlcy1pZHItdXBkYXRlLWF0dHJpYi1sb3ctYml0cy1maXgtMDAuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPkkgYWdyZWUgd2l0aCBKYWtvYi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibHVl Ij5HaXZlbiB0aGF0IGltcGxlbWVudGF0aW9ucyBleGlzdCB0aGF0IGRvbuKAmXQgcHJvcGFnYXRl IHRoZXNlIGJpdHMgdG9kYXksIGlmIHlvdSBkbyB1cGRhdGUgNDI3MSwgYXQgd2hhdCBwb2ludCB3 b3VsZCB5b3UgYmUgd2lsbGluZyB0byBkZWZpbmUgbmV3IGZsYWdzDQogYW5kIHRydXN0IHRoYXQg YWxsIHJvdXRlcnMgd291bGQgcHJvcGFnYXRlIHRoZW0gcHJvcGVybHk/IEdpdmVuIHRoZSBhbWJp Z3VpdHkgb2YgdGhlIHdvcmRpbmcgaW4gNDI3MSwgaXQgc2VlbXMgc2FmZXIgdG8gc2lnbmFsIGFu eSBuZXcgYmVoYXZpb3Igd2l0aGluIHRoZSBuZXcgYXR0cmlidXRlIHZhbHVlLg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlJvYjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJl Zj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4g WzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmlkci1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFrb2IgSGVpdHo8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDA3LCAyMDEzIDc6MDUgUE08YnI+DQo8Yj5Ubzo8L2I+ IEJyaWFuIERpY2tzb247IEpvaG4gTGVzbGllPGJyPg0KPGI+Q2M6PC9iPiBpZHIgd2c7IFN1c2Fu IEhhcmVzOyBKb2huIEcuIFNjdWRkZXI8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIDIg d2VlayBXRyBhZG9wdGlvbiAmYW1wOyBMQyBvbiBkcmFmdC1oYXJlcy1pZHItdXBkYXRlLWF0dHJp Yi1sb3ctYml0cy1maXgtMDAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVv dDs7Y29sb3I6cHVycGxlIj5JdCdzIHRvbyBsYXRlLiBUaG9zZSBiaXRzIGFyZSBkZWFkLiBUaGVy ZSdzIHBsZW50eSBtb3JlIGJpdHMgaW4gdGhlIHNlYS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7 O2NvbG9yOnB1cnBsZSI+RXZlbiBpZiB5b3VyIHBlZXIgc3VwcG9ydHMgdGhlbSwgeW91ciBwZWVy J3MgcGVlciBtaWdodCBub3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0x1Y2lkYSBDb25zb2xlJnF1b3Q7O2NvbG9yOnB1cnBsZSI+RXZlbiBmb3Igbm9u LXRyYW5zaXRpdmUgYXR0cmlidXRlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7THVjaWRhIENvbnNvbGUmcXVvdDs7Y29sb3I6cHVycGxlIj5UaGUgYmVz dCB3ZSBjYW4gZG8gaXMgc2V0IHRoZW0gdG8gMCwgc28gbm90aGluZyBicmVha3MuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pi0tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmFrb2IgSGVpdHouPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBwdXJwbGUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5n PSJFTi1VUyI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9z cGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJl Zj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4g WzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmlkci1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gRGlja3Nvbjxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMDcsIDIwMTMgMjoxMiBQTTxicj4NCjxiPlRvOjwv Yj4gSm9obiBMZXNsaWU8YnI+DQo8Yj5DYzo8L2I+IGlkciB3ZzsgSm9obiBHLiBTY3VkZGVyOyBT dXNhbiBIYXJlczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkcl0gMiB3ZWVrIFdHIGFkb3B0 aW9uICZhbXA7IExDIG9uIGRyYWZ0LWhhcmVzLWlkci11cGRhdGUtYXR0cmliLWxvdy1iaXRzLWZp eC0wMC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SSBoYXZlIGFuIG9wZW4gcXVlc3Rpb24sIHByaW1hcmlseSBpbnRlbmRlZCBm b3IgdGhlIGZvbGtzICZxdW90O2V4cGVyaW1lbnRpbmcmcXVvdDsgYWNyb3NzIHRoZSBJbnRlcm5l dCAoYW5kIGNhdXNpbmcgbXVjaCBleGNpdGVtZW50KToNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoZXJlIGlzIGV2ZW4gdGhlIHNsaWdodGVzdCBwb3NzaWJp bGl0eSBvZiB1c2luZyBzb21lIG9mIHRoZXNlIGJpdHMgaW4gZnV0dXJlLCBSRUdBUkRMRVNTIG9m IGZvciB3aGF0LCBtYXliZSB0aGUgbmVlZCB0byB1c2UgdGhlbSBhY3Jvc3MgdW5hd2FyZSBwYXJ0 aWVzIGNvdWxkIGJlIHNpZ25hbGxlZC9uZWdvdGlhdGVkPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIGV4YW1wbGUsIGEgbmV3IENhcGFiaWxpdHkg dG8gYmUgbmVnb3RpYXRlZCwgY2FsbCBpdCBET05UX01FU1NfV0lUSC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIG5lZ290aWF0ZWQsIHRoZSB1bmFt YmlndW91cyBiZWhhdmlvciBvZiAmcXVvdDtwYXNzIHVuY2hhbmdlZCZxdW90OyBhcHBsaWVzIHRv IHRoZSBiaXRzIGluIHF1ZXN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+SW4gYW55IG90aGVyIGNhc2UsIGFueSBwcmVzdW1wdGlvbiBhYm91dCB0 aGUgYml0cyBnZXR0aW5nIHRocm91Z2ggc2hvdWxkIG5vdCBiZSBtYWRlLCBhbmQgdGhlIGN1cnJl bnQgJnF1b3Q7TVVTVCBCRSBaRVJPJnF1b3Q7IHNob3VsZCBhcHBseSB0byBhbGwuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIHdvdWxkIHRoZW4g bWVhbiwgaWYgTk9UIG5lZ290aWF0ZWQsIGFsbG93IGFueSwgYnV0IGl0IGlzIG9rYXkgdG8gc3Rv bXAgb24gdGhlbSAoYnV0IG5vdCByZXF1aXJlZCEhKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoZSBmb2xrcyBVU0lORyB0aGUgYml0cyByZWFs bHkgd2FudCB0byBkbyBtb3JlIGV4cGVyaW1lbnRzIGFuZC9vciB1c2UgdGhlbSwgYSBxdWljayBJ LUQgb24gdGhlIG5ldyBDYXBhYmlsaXR5IHdvdWxkIGJlIG5pY2UsIGFuZCBJIHdvdWxkIHN1cHBv cnQgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5X aGlsZSBJIHdvdWxkIGxlYW4gdG93YXJkcyBBTFdBWVMgemVyb2luZyBvdXQgdGhlIGJpdHMsIEkg Y2FuIHNlZSB0aGUgYXJndW1lbnQgdGhlIG90aGVyIHdheSwgYW5kIGFtIGZpbmUgd2l0aCB0aGUg Y3VycmVudCBkcmFmdCBpbiBMQywgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IGlzIFNIT1VMRCBv ciBNVVNULjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ccmlhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gTW9uLCBK YW4gNywgMjAxMyBhdCAzOjIyIFBNLCBKb2huIExlc2xpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpv aG5AamxjLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmpvaG5AamxjLm5ldDwvYT4mZ3Q7IHdyb3RlOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdXNhbiBIYXJlcyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgT3VyIGRpc2N1c3Npb24gb24gdGhlIGxvd2VyLW9y ZGVyIGZvdXIgYml0cyBjYW1lIHRvIHJlc29sdXRpb248YnI+DQomZ3Q7IHRvIGNsYXJpZnkgdGhl IFJGQyA0NzIxIHRleHQuIEpvaG4gYW5kIEkgZGVjaWRlZCB0aGUgYmVzdCB3YXk8YnI+DQomZ3Q7 IHRvIG1ha2Ugc3VyZSBhbGwgcGFydGllcyBhZ3JlZSB0byB0aGUgc29sdXRpb24gaXMgdG8gZmxv YXQ8YnI+DQomZ3Q7IGEgbWluaS1kcmFmdCB0aGF0IHN1bW1hcmllcyB0aGlzIGVkaXRvcmlhbCBm aXggdG8gUkZDNDcyMS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCZWNhdXNlIHRoZSBtaW5pLWRyYWZ0 IGlzIHNvIHNpbXBsZSwgd2UncmUgZ29pbmcgdG8gZG8gYTxicj4NCiZndDsgMiBXRyBhZG9wdGlv biBhbmQgTEMgY2FsbCBjb21iaW5lZC4gJm5ic3A7SWYgYW55b25lIG9iamVjdHMsIHdlJ2xsPGJy Pg0KJmd0OyBkcm9wIGJhY2sgdG8ganVzdCBhIDIgd2VlayBXRyBhZG9wdGlvbi48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBUaGUgZHJhZnQgbmFtZSBpczo8YnI+DQomZ3Q7ICZuYnNwO1VwZGF0ZSBBdHRy aWJ1dGUgRmxhZyBMb3cgQml0cyBDbGFyaWZpY2F0aW9uPGJyPg0KJmd0OyAmbmJzcDtkcmFmdC1o YXJlcy1pZHItdXBkYXRlLWF0dHJpYi1sb3ctYml0cy1maXgtMDA8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsgJm5ic3A7SSB0aGluayB3ZSB3aWxsIG5lZWQgdG8gYmFjayBvZmYgdGhlICZxdW90O01VU1Qg cHJvcGFnYXRlIHRoZXNlIGZsYWdzPGJyPg0KYXMgcmVjZWl2ZWQmcXVvdDsuPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwO1dlIGFyZSBnb2luZyB0byBoYXZlLCBmb3IgYSBudW1iZXIgb2YgeWVhcnMs IGxlZ2FjeSBlcXVpcG1lbnQ8YnI+DQp3aGljaCByZXNldHMgdGhlc2UgYml0cyB0byB6ZXJvIHdo ZW4gcHJvcGFnYXRpbmc6IGFmdGVyIGFsbCwgaXQnczxicj4NCjEwMCUgY29tcGxpYW50IHdpdGgg NDI3MSB0byBkbyBzby4gQWxzbywgSSBkb24ndCB0aGluayB3ZSBjYW4gYmU8YnI+DQpzdXJlIHRo YXQgc29tZSBtb2RpZmljYXRpb24gb2YgdGhlc2UgYml0cyBpbiBwcm9wYWdhdGlvbiB3aWxsIG5l dmVyPGJyPg0KcHJvdmUgdXNlZnVsLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtJIHN1Z2dlc3Qg Y2hhbmdpbmcgdGhhdCBNVVNUIHRvIGEgU0hPVUxEOjxicj4NCiZxdW90Ozxicj4NCiZxdW90OyBU aGUgbG93ZXItb3JkZXIgZm91ciBiaXRzIG9mIHRoZSBBdHRyaWJ1dGUgRmxhZ3Mgb2N0ZXQgYXJl PGJyPg0KJnF1b3Q7IHVudXNlZC4gJm5ic3A7VGhleSBNVVNUIGJlIHplcm8gd2hlbiBvcmlnaW5h dGVkLiAmbmJzcDtXaGVuIHJlY2VpdmVkLCBhbnk8YnI+DQomcXVvdDsgdmFsdWUgTVVTVCBiZSBh Y2NlcHRlZC4gJm5ic3A7V2hlbiBhIEJHUCBzcGVha2VyIHByb3BhZ2F0ZXMgYW48YnI+DQomcXVv dDsgYXR0cmlidXRlLCBpdCBTSE9VTEQgcHJvcGFnYXRlIHRoZXNlIGZsYWdzIGFzIHJlY2VpdmVk Ljxicj4NCjxicj4NCi0tPGJyPg0KSm9obiBMZXNsaWUgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2hu QGpsYy5uZXQiPmpvaG5AamxjLm5ldDwvYT4mZ3Q7PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZHIgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI8L2E+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3ByZT4NCjxwcmU+cGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZy YW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48 L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48 L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91Ljxv OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K PC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_53C29892C857584299CBF5D05346208A1233C0PEXCVZYM11corpora_-- From iesg-secretary@ietf.org Thu Jan 10 08:17:30 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A16921F88E1; Thu, 10 Jan 2013 08:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIh+lv1qn-+7; Thu, 10 Jan 2013 08:17:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB2321F8844; Thu, 10 Jan 2013 08:17:28 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130110161728.8829.5625.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2013 08:17:28 -0800 Cc: idr@ietf.org Subject: [Idr] Last Call: (Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID) to Informational RFC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 16:17:30 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document requests IANA to deprecate the BGP path attributes DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet Draft and a Historic RFC, respectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-dpa-etal/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-dpa-etal/ballot/ No IPR declarations have been submitted directly on this I-D. From jmpolk@cisco.com Tue Jan 8 21:07:49 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4BC21F8445; Tue, 8 Jan 2013 21:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s37U5Z-8doG2; Tue, 8 Jan 2013 21:07:48 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2BD21F843F; Tue, 8 Jan 2013 21:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3019; q=dns/txt; s=iport; t=1357708068; x=1358917668; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=ZlILtSb3qrIBWKxikuoQPozhyIWrwBBZ0eNj/Dp1a8E=; b=S3dmBVVz0+EL1UzSw/tJv6+Vye6eHeJGNOPOUJWxpxhdUJMexUgxxbRL QfMWBNJYudvrXjW6usSVpjeSqloyntZRKe82zVUSSsARij0WtoVR11ym0 Rk4AP0WESJN28KgSnHKYpdY7QZEOufH9x7IW6rK+A2NhaD17va0NBd9Yi M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGX67FCtJXG9/2dsb2JhbABFvV8Wc4IeAQEBBDgCPxAHBBgJFRAPCj4GiCqpdY0hkRUDiGGddIMT X-IronPort-AV: E=Sophos;i="4.84,435,1355097600"; d="scan'208";a="160367329" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 09 Jan 2013 05:07:47 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0957lwU008376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 05:07:47 GMT Message-Id: <201301090507.r0957lwU008376@rcdn-core2-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Jan 2013 23:07:47 -0600 To: Brian E Carpenter From: James Polk In-Reply-To: <50EAE8D9.5090200@gmail.com> References: <20130103205630.3871.46704.idtracker@ietfa.amsl.com> <50EAE8D9.5090200@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk X-Mailman-Approved-At: Mon, 14 Jan 2013 08:15:47 -0800 Cc: idr@ietf.org, draft-ietf-idr-sla-exchange.all@tools.ietf.org, tsvwg-chairs@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-sla-exchange-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 05:07:49 -0000 Brian I, for one, want to thank you for pointing this draft out to the TSVWG chairs. It is now on our radar. Speaking for me, individually, and as a chair of TSVWG, I want to see this run by TSVWG as a whole for the reasons you mention. James At 09:25 AM 1/7/2013, Brian E Carpenter wrote: >Hi, > >I don't understand which reference model for inter-domain SLAs >is being used here. There is an arbitrary list of element types >(IP_DSCP, MPLS_TC, 802_1Q_COS, 802_1Q_DEI, PHB_ID) and then >an arbitrary list of some QoS metrics. Presumably some of those >metrics map on to some of the element types, but it isn't obvious >and I am certain there are gaps. > >I don't think you can answer this with the text at the end of >Section 6: > > > There are well-defined recommendations that exist for traffic class > > mapping between two technologies. Receiver MAY use those defined > > recommendations for traffic class mapping or MAY define its own as > > per its network Traffic Class service definition to map to advertised > > Traffic Classes. It is completely up to the receiver how to define > > such traffic class mapping. > >Firstly, if there are such recommendations, they should be given as >references. Secondly, why was the arbitrary set of QoS metrics chosen >and how do we know that they are necessary and sufficient? (For >example, I don't see any metric for drop rate, and for some traffic >classes that is an important metric.) > >I think this draft needs to be discussed in TSVWG before it goes >much further. A consistent model for QoS metric signalling is needed >before we standardise a mapping onto IDR. > >Nits >---- > >[RFC2474], [RFC2475] and [RFC3140] are listed as references >(presumably for IP_DSCP and PHB_ID) but they are not cited in the >text. That will not get through the final ID-nits check. > >Also [RFC2475] is listed as a Normative reference, but it should >be Informative. > >Why is [RFC3552] listed as a reference? > >Why is *obsoleted* [RFC1771] listed as a reference? > >Why is [RFC4760] *not* listed, since this needs to work for IPv6? > >The English in this draft is quite painful in many places. Here >is one sentence chosen at random: > > > Taking same voice service as an > > example, given Provider already may provision definition of EF code- > > point for such, signaling this code-point traffic class from PE to CE > > along with low latency service definition, omits administrator at the > > CE to worry about such translation. > >I'm guessing that this means: > > Taking voice service as an > example, a given provider might already provision the EF code- > point for such traffic. Signaling the code-point for this > traffic class from PE to CE, > with a low latency service definition, would avoid manual > operations by the administrator at the > CE. > >Please run ID-nits and fix the 2 errors and 11 warnings. > >Regards > Brian Carpenter From chandra.appanna@yahoo.com Mon Jan 14 18:37:30 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93B711E809B for ; Mon, 14 Jan 2013 18:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYJBk-Xu-B2s for ; Mon, 14 Jan 2013 18:37:28 -0800 (PST) Received: from nm22.bullet.mail.bf1.yahoo.com (nm22.bullet.mail.bf1.yahoo.com [98.139.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id 66B0821F8BBB for ; Mon, 14 Jan 2013 18:37:28 -0800 (PST) Received: from [98.139.212.144] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jan 2013 02:37:27 -0000 Received: from [98.139.212.200] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jan 2013 02:37:27 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 15 Jan 2013 02:37:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 830094.9419.bm@omp1009.mail.bf1.yahoo.com Received: (qmail 22852 invoked by uid 60001); 15 Jan 2013 02:37:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358217447; bh=LxEi3fGA1sPPkRzmIMCYtS+mTa1pbv8CcAvKVyLshxs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Ap4CMtSlCgElPp7FOrgtkmCZTevm9IhWmVURdxn4wLAhgEiNqBpJEnb4P6zF4s+5Bfu8rFoDk4ytrg07Daheqs7IgqRw9iGYLZd/Pi2wJJIOyKYbxOsqSsLcl/0dJ0VP4lMExtRDazp9n1fWNw6shDt5GSbtb58540CzD6pkvv8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6G1Oh4ckxn9Anm7u+Ah6IE5gZwB3WKPX8GRHsJiQxSpOQBUf3Z6pBVAZiiSug05cFHkJB29m5o079nptuRobv8SIp8X8AaUSzIMc1+3TNu7yBtUm3ySlNhTMhtsJcfJUx7lJQGaO4e0oULUMDAbwOfY0LwoL0xL0LAKlMMYvav4=; X-YMail-OSG: MwGQtWsVM1mnExkxST_EzUqWZ3Mq._.gucF6b9QgF4cenIs N4yuXW_EnKJLtG2XJF1OkR6ACcihiN094AgIdQTwbqKYK43SW7PqMerMk17l oyZ8S06aPHx69t.8q7Vm8XVRKCtNsxXPak3rRUIB8qk_4T60Gnz5YMQsv5cI zs8QatPjdfSiiYDwJ9AaIV_elRj_dG7jsfmczwg.nlnglqyIm80qRA0vicjj oBobMUZLt7kjS7jORByYG0dpX6XjjE4A13_yzGYuJtksr.Ujc2piDJ7WuDVa EeVhbvNwG2fdOU1BbHx_hEVpqwEXQ05dZBNLo1xZ6_xnRzk_k5_az8Dd9FRt QKy60KoiIT.cYpV.USPUfpO3KF84qwCtPquEabFVSeh1uBVsPJphvmDyA.0o o145BOK63c5HMi1r7zASD0DmxrlqrW_xabuj8pMwcDouam6vPz.ngwa_oYip jNkbbY_7vH.HvmUvWN3q.6XDfUFLIiMqa.mH2J3YoySTg8Oh0Xbt.EQzyc.T _inkMBg2l.mJtsofHWgvpjy_q Received: from [4.53.128.218] by web162901.mail.bf1.yahoo.com via HTTP; Mon, 14 Jan 2013 18:37:27 PST X-Rocket-MIMEInfo: 001.001, UmF0aGVyIGxhdGUgcmVwbHkgb24gdGhpcyB0b3BpYy4uIEJ1dCBJIGhhcHBlbiB0byBhZ3JlZSB3aXRoIEphcmVkLgpJIGRpZCBzdGFydCBvdXQgdGhpbmtpbmcgdGhhdCB0aGUgYmdwIGVycm9yIGhhbmRsaW5nIGlkZWEgd2FzIGEgbmV3CnR3aXN0IG9mIGEgc29sdXRpb24gdGhhdCB3YXMgdmVyeSBpbnRlcmVzdGluZyBidXQgYWZ0ZXIgYWxsIHRoaXMgZGViYXRlCmFuZCBteSBvd24gaW50cm9zcGVjdGlvbiwgSSBhbSBhY3R1YWxseSBiYWNrIGluIHRoZSBjYW1wIG9mIG5vdCBiZWxpZXZpbmcKaW4gdGhlIGkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> Message-ID: <1358217447.9527.YahooMailNeo@web162901.mail.bf1.yahoo.com> Date: Mon, 14 Jan 2013 18:37:27 -0800 (PST) From: Chandra Appanna To: Jared Mauch , Michael Long In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1846104760-87129825-1358217447=:9527" Cc: "idr@ietf.org" , "grow@ietf.org" , Tony Li Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Chandra Appanna List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 02:37:30 -0000 ---1846104760-87129825-1358217447=:9527 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Rather late reply on this topic.. But I happen to agree with Jared.=0AI did= start out thinking that the bgp error handling idea was a new=0Atwist of a= solution that was very interesting but after all this debate=0Aand my own = introspection, I am actually back in the camp of not believing=0Ain the ide= a of soft corrections in the face of malformed updates and such=0Asituation= s. I for one have not seen a lot of real data from the SPs and=0Aother newe= rusers of BGP in my dealings of many years that reflect the need for=0Asuch= solutions in the real world. I do remain convinced that this is=0Astill a = very interesting and challenging and 's..y' software and protocol=0Adevelop= ment point but from a practical point of view I am not sure.=0AI have also = seen discussions in development teams about how to structure=0Acode to hand= le such treat-as-withdraw scenarios and it seems to me=0Athat it is very po= ssible that it might only make code more fragile than robust.=0AIf only I h= ad a penny for every time I thought I had written bug free=0Aautomatic bug = handling code... :)=0A=0A0.02,=0AChandra.=0A=0A=0A=0A=0A___________________= _____________=0A From: Jared Mauch =0ATo: Michael Lo= ng =0ACc: idr@ietf.org; grow@ietf.org; Tony Li =0ASent: Thursday, January 3, 2013 11:58 AM=0ASubject: Re: [Idr] [= GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt=0A= =0A=0AOn Jan 3, 2013, at 2:35 PM, Michael Long wrote:=0A=0A> =0A> On Jan 3= , 2013, at 10:00 AM, Tony Li wrote:=0A>> =0A>> =0A>> All = of the marketing that you're doing here is positioning this as a 'solution'= .=A0 It's not.=A0 Yes, it will stop the flap, but it does NOTHING to fix or= deal with the underlying bug.=A0 All it does is gloss it over, and as such= , it will have implications in the field whereby this papers over real bugs= and we have now promoted BGP errors into RIB errors.=A0 That's NOT making = things easier to debug, that's just applying a band-aid.=0A> =0A> I underst= and what you are saying and I agree 100%, however, from an my operations pe= rspective the "fix" is the same. Either upgrade to fixed code or policy out= the offending announcement. I would rather deal with a customer routing is= sue vs a frantic call from our noc saying 15+ att peers globally are bounci= ng. The latter being a much bigger impact on our network. =0A=0AI'm very co= ncerned with the case of ignoring a route update and having a month-long di= scussion about why some route is missing from the $carrier_a network when i= t's being sent from $carrier_b and they show it going out just fine.=0A=0AY= ou don't know there's an issue until someone reports it and your long-tail = to problem resolution takes forever.=0A=0A> I can live with a couple of /24= 's not working for a few customers. I can't have 15+ peers bouncing because= of bad updates and even more peers bouncing because of missed keepalives d= ue to cpu pegged trying to deal with 15 peers bouncing globally. =0A=0AWhil= e related, this is an implementation defect on the part of vendors and thei= r poorly optimized TCP and BGP implementations being unable to get their ba= sic job done.=A0 I recall vendors blaming our "slow" system CPU then finall= y fixing their logic defect that always returned 1 or 0 when it thought it = was idle.=A0 (sometimes those if statements look really complex).=0A=0A>> A= more constructive way to address the real problem here would be to talk ab= out whether we should even re-establish the session after an error.=A0 Long= ago, we made an implementation decision to simply retry.=A0 That would see= m to be the real issue at hand.=0A> =0A> I would back this provided adequat= e logging as to why the session is down. It would be much like tripping max= -prefixes where we could hard clear a single single session for debug. I co= uld live with this. =0A=0AI certainly agree there needs to be better loggin= g from the vendors.=0A=0AI remain convinced that attempts to address this p= roblem will create more complex situations vs provide the desired result of= a stable BGP core.=0A=0A- Jared=0A________________________________________= _______=0AIdr mailing list=0AIdr@ietf.org=0Ahttps://www.ietf.org/mailman/li= stinfo/idr ---1846104760-87129825-1358217447=:9527 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Rather late reply on this topic.. But I happen to agree with Jared.
I did start out= thinking that the bgp error handling idea was a new
twist of a solution= that was very interesting but after all this debate
and my own introspe= ction, I am actually back in the camp of not believing
in the idea of so= ft corrections in the face of malformed updates and such
situations. I f= or one have not seen a lot of real data from the SPs and
other newer use= rs of BGP in my dealings of many years that reflect the need for
such so= lutions in the real world. I do remain convinced that this is
still a ve= ry interesting and challenging and 's..y' software and protocol
developm= ent point but from a practical point of view I am not sure.
I have also seen discussions in development teams about how to structure
code to ha= ndle such treat-as-withdraw scenarios and it seems to me
that it is very= possible that it might only make code more fragile than robust.
If only= I had a penny for every time I thought I had written bug free
automatic= bug handling code... :)

0.02,
Chandra.

=

From: Jared Mauch <jared@puck.nether.n= et>
To: Michael Lon= g <mlong@us.ntt.net>
Cc: idr@ietf.org; grow@ietf.org; Tony Li <tony.li@tony.li>
= Sent: Thursday, January 3, 2013 11= :58 AM
Subject: Re: [I= dr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.t= xt


On Jan 3, 2013, at 2:35 PM, Michael Long wrot= e:

>
> On Jan 3, 2013, at 10:00 AM, Tony Li <tony.li@tony.li= > wrote:
>>
>>
>> All of the marketing = that you're doing here is positioning this as a 'solution'.  It's not.=   Yes, it will stop the flap, but it does NOTHING to fix or deal with = the underlying bug.  All it does is gloss it over, and as such, it wil= l have implications in the field whereby this papers over real bugs and we = have now promoted BGP errors into RIB errors.  That's NOT making thing= s easier to debug, that's just applying a band-aid.
>
> I understand what you are saying and I agree 100%, however, from an my opera= tions perspective the "fix" is the same. Either upgrade to fixed code or po= licy out the offending announcement. I would rather deal with a customer ro= uting issue vs a frantic call from our noc saying 15+ att peers globally ar= e bouncing. The latter being a much bigger impact on our network.

I= 'm very concerned with the case of ignoring a route update and having a mon= th-long discussion about why some route is missing from the $carrier_a netw= ork when it's being sent from $carrier_b and they show it going out just fi= ne.

You don't know there's an issue until someone reports it and you= r long-tail to problem resolution takes forever.

> I can live wit= h a couple of /24's not working for a few customers. I can't have 15+ peers= bouncing because of bad updates and even more peers bouncing because of mi= ssed keepalives due to cpu pegged trying to deal with 15 peers bouncing globally.

While related, this is an implementation defect= on the part of vendors and their poorly optimized TCP and BGP implementati= ons being unable to get their basic job done.  I recall vendors blamin= g our "slow" system CPU then finally fixing their logic defect that always = returned 1 or 0 when it thought it was idle.  (sometimes those if stat= ements look really complex).

>> A more constructive way to add= ress the real problem here would be to talk about whether we should even re= -establish the session after an error.  Long ago, we made an implement= ation decision to simply retry.  That would seem to be the real issue = at hand.
>
> I would back this provided adequate logging as to= why the session is down. It would be much like tripping max-prefixes where= we could hard clear a single single session for debug. I could live with t= his.

I certainly agree there needs to be better logging from the vendors.

I remain convinced that attempts to address this probl= em will create more complex situations vs provide the desired result of a s= table BGP core.

- Jared
_________________________________________= ______
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/i= dr


---1846104760-87129825-1358217447=:9527-- From nick@inex.ie Tue Jan 15 07:57:19 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7963B21F8623; Tue, 15 Jan 2013 07:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MENabYJjqBzr; Tue, 15 Jan 2013 07:57:19 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A737921F8574; Tue, 15 Jan 2013 07:57:17 -0800 (PST) X-Envelope-To: grow@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id r0FFt3cT021724 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 15 Jan 2013 15:55:09 GMT (envelope-from nick@inex.ie) Message-ID: <50F57C56.5060501@inex.ie> Date: Tue, 15 Jan 2013 15:57:10 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Chandra Appanna References: <03c501cde845$54f82b30$fee88190$@highwayman.com> <04FA2CED-CC6E-486D-BCAF-2F1B37B0D778@puck.nether.net> <22E579A6-6732-476A-A0F7-4D9CB87E4069@tony.li> <1358217447.9527.YahooMailNeo@web162901.mail.bf1.yahoo.com> In-Reply-To: <1358217447.9527.YahooMailNeo@web162901.mail.bf1.yahoo.com> X-Enigmail-Version: 1.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 16 Jan 2013 08:17:56 -0800 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 15:57:19 -0000 On 15/01/2013 02:37, Chandra Appanna wrote: > I for one have not seen a lot of real data from the SPs and > other newer users of BGP in my dealings of many years that reflect the need for > such solutions in the real world. Chandra, This particular problem tends only to crop up every so often, but when it happens, the results can be devastating on a global scale, causing wide-scale outages across the entire Internet. The last couple of times, the problem has been caused by malformed attributes and has affect entire products lines, e.g. all Junipers routers in the propagation path, or all Cisco IOS boxes, or whatever. Or better still, when you have one vendor for your routers and another vendor for your RRs, you can be guaranteed of failure until all your upstreams figure out some way of filtering out the offending UPDATEs. It is a very real and very serious problem. There is lots of noise about this on nanog-l. Nick From wwwrun@rfc-editor.org Wed Jan 16 08:10:47 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9E421F8AD8 for ; Wed, 16 Jan 2013 08:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O36J1LwHHDon for ; Wed, 16 Jan 2013 08:10:47 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3E421F8AD4 for ; Wed, 16 Jan 2013 08:10:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 82A86B1E002; Wed, 16 Jan 2013 07:59:49 -0800 (PST) To: yakov@juniper.net, tony.li@tony.li, skh@nexthop.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20130116155953.82A86B1E002@rfc-editor.org> Date: Wed, 16 Jan 2013 07:59:49 -0800 (PST) X-Mailman-Approved-At: Wed, 16 Jan 2013 08:17:56 -0800 Cc: lhui5484@gmail.com, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4271 (3459) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 16:10:47 -0000 The following errata report has been submitted for RFC4271, "A Border Gateway Protocol 4 (BGP-4)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3459 -------------------------------------- Type: Editorial Reported by: Lawrence Hui Section: 6.8 Original Text ------------- If a pair of BGP speakers try to establish a BGP connection with each other simultaneously, then two parallel connections well be formed. Corrected Text -------------- If a pair of BGP speakers try to establish a BGP connection with each other simultaneously, then two parallel connections will be formed. Notes ----- This edit will replace the "well" with "will". 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. -------------------------------------- RFC4271 (draft-ietf-idr-bgp4-26) -------------------------------------- Title : A Border Gateway Protocol 4 (BGP-4) Publication Date : January 2006 Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Thu Jan 17 08:16:09 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A293C21F85BF for ; Thu, 17 Jan 2013 08:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, J_CHICKENPOX_71=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrBiPQ6mAJti for ; Thu, 17 Jan 2013 08:16:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14D21F857E for ; Thu, 17 Jan 2013 08:16:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 40591B1E002; Thu, 17 Jan 2013 08:05:17 -0800 (PST) To: yakov@juniper.net, tony.li@tony.li, skh@nexthop.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20130117160517.40591B1E002@rfc-editor.org> Date: Thu, 17 Jan 2013 08:05:17 -0800 (PST) X-Mailman-Approved-At: Thu, 17 Jan 2013 08:18:40 -0800 Cc: lhui5484@gmail.com, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4271 (3464) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:16:09 -0000 The following errata report has been submitted for RFC4271, "A Border Gateway Protocol 4 (BGP-4)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3464 -------------------------------------- Type: Editorial Reported by: Lawrence Hui Section: 9.1.1 Original Text ------------- The Phase 1 decision function is a separate process,f which completes when it has no further work to do. Corrected Text -------------- The Phase 1 decision function is a separate process, which completes when it has no further work to do. Notes ----- This edit will remove the "f". 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. -------------------------------------- RFC4271 (draft-ietf-idr-bgp4-26) -------------------------------------- Title : A Border Gateway Protocol 4 (BGP-4) Publication Date : January 2006 Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From john@jlc.net Thu Jan 17 08:48:48 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546D521F8512 for ; Thu, 17 Jan 2013 08:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.161 X-Spam-Level: X-Spam-Status: No, score=-106.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iANz-LFiPYH for ; Thu, 17 Jan 2013 08:48:47 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9430E21F84EB for ; Thu, 17 Jan 2013 08:48:45 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9B7FD33D5A; Thu, 17 Jan 2013 11:48:44 -0500 (EST) Date: Thu, 17 Jan 2013 11:48:44 -0500 From: John Leslie To: Brian Dickson Message-ID: <20130117164844.GF41685@verdi> References: <074d01cdd536$173f5830$45be0890$@highwayman.com> <9474D8DC-30FF-4C52-9504-15CBCC47E7D8@ericsson.com> <07df01cdd661$f28ef7c0$d7ace740$@highwayman.com> <36E98AE5-3EF8-4738-9982-42B9CA0BAAF5@rob.sh> <005001cdd6da$099f1e90$1cdd5bb0$@highwayman.com> <828AAFF5-0260-4AA6-BBDC-6C1F69919837@ericsson.com> <009001cdd6ff$1c982530$55c86f90$@highwayman.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:48:48 -0000 Brian Dickson wrote: > > It is unfortunate that UPDATE messages do not have any sort of identifier. Indeed! One hopes BGP5 won't suffer from this... > It would be nice to be able to have the receiver send a NOTIFICATION that > says, in effect, UPDATE #foo was garbled, please send JUST the afi/safi & > NLRI so I know what to ignore. The downside, of course, is that the sender needs to agree to do so. But IMHO, we're not going to get fully "safe" error recovery without involving the sender. (There is a sign in my office, which everyone who has worked here has had to "write 100 times," saying, "Error correction is the most error-prone operation in computing.") > Maybe this could be handled via another UPDATE Attribute - the > identification for an UPDATE itself? > Then refer to this in the appropriate NOTIFICATION, type 3, new subtype, > with parameter identifying the problem UPDATE? There are various ways to do this. I, being a bear of small brain, chose to do it with a new message type, thus entirely removing any question of pulling it out of an UPDATE message. (In BGP5, it should be a required field early in the UPDATE!) > Then there is the question of the original UPDATE (generally on-the-fly > data). If the error happens soon enough, maybe the sender still has the > UPDATE in his/her outgoing TCP buffer? Actually, this wouldn't be hard, provided the receiver gives a prompt enough signal that an UPDATE has been "successfully" received. > Otherwise, this would mean having to hold onto UPDATEs for possibly longer > than desired. > (LRU for buffer management is so very convenient when it is available, of > course. Pack rat coding rules.) But all the sender really needs to save is the NLRI(s) deserving to be withdrawn. That's a smaller amount of data... > And of course, this pushes the "ACK" further up the stack, from TCP to the > parent application (BGP). Again, maybe not that bad an idea, but definitely > non-trivial. IMHO, the ACK needs to be further up the stack. Sooner or later we'll run into a case where the error is only apparent in "context", but the proper correction is to back out the UPDATE and ask the sender to generate a "safer" version of it. > (I think this is more reliable, but again requires changes to both ends. > The net benefit can be substantial, in terms of not having to "just guess" > when the UPDATE is already known to be busted.) Exactly! -- John Leslie From internet-drafts@ietf.org Mon Jan 21 15:56:21 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848CA21F86DA; Mon, 21 Jan 2013 15:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT-DRIP7ArWF; Mon, 21 Jan 2013 15:56:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258B521F86F4; Mon, 21 Jan 2013 15:56:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130121235621.31113.70905.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2013 15:56:21 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-link-bandwidth-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 23:56:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : BGP Link Bandwidth Extended Community Author(s) : Pradosh Mohapatra Rex Fernando Filename : draft-ietf-idr-link-bandwidth-06.txt Pages : 6 Date : 2013-01-21 Abstract: This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-link-bandwidth-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jan 22 06:49:04 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B115521F8988; Tue, 22 Jan 2013 06:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATJJ9QLxm61L; Tue, 22 Jan 2013 06:49:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D1121F86EA; Tue, 22 Jan 2013 06:49:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130122144903.3863.65108.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 06:49:03 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-flowspec-oid-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:49:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Revised Validation Procedure for BGP Flow Specifications Author(s) : James Uttaro Clarence Filsfils Pradosh Mohapatra David J. Smith Filename : draft-ietf-idr-bgp-flowspec-oid-01.txt Pages : 9 Date : 2013-01-22 Abstract: This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 requires that the originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP flow specifications. Though it is possible to disseminate such flow specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables flow specifications to be originated from a centralized BGP route controller. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-flowspec-oid-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Tue Jan 22 20:42:22 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAA421F845F for ; Tue, 22 Jan 2013 20:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.65 X-Spam-Level: X-Spam-Status: No, score=-101.65 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqz9E8-Y1tPR for ; Tue, 22 Jan 2013 20:42:22 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 457F921F87B6 for ; Tue, 22 Jan 2013 20:42:22 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DF35472E039; Tue, 22 Jan 2013 20:31:09 -0800 (PST) To: enkechen@cisco.com, yakov@juniper.net, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20130123043109.DF35472E039@rfc-editor.org> Date: Tue, 22 Jan 2013 20:31:09 -0800 (PST) Cc: idr@ietf.org, david@opensourcerouting.org, rfc-editor@rfc-editor.org Subject: [Idr] [Technical Errata Reported] RFC5291 (3468) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 04:42:23 -0000 The following errata report has been submitted for RFC5291, "Outbound Route Filtering Capability for BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5291&eid=3468 -------------------------------------- Type: Technical Reported by: David Lamparter Section: 5 Original Text ------------- 5. Outbound Route Filtering Capability A BGP speaker that is willing to receive ORF entries from its peer, or a BGP speaker that would like to send ORF entries to its peer, advertises this to the peer by using the Outbound Route Filtering Capability, as described below. The Outbound Route Filtering Capability is a new BGP Capability [BGP-CAP] defined as follows: Capability code: 3 Capability length: variable Capability value: one or more of the entries as shown in Figure 3. +--------------------------------------------------+ | Address Family Identifier (2 octets) | +--------------------------------------------------+ | Reserved (1 octet) | +--------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +--------------------------------------------------+ | Number of ORFs (1 octet) | +--------------------------------------------------+ | ORF Type (1 octet) | +--------------------------------------------------+ | Send/Receive (1 octet) | +--------------------------------------------------+ | ... | +--------------------------------------------------+ | ORF Type (1 octet) | +--------------------------------------------------+ | Send/Receive (1 octet) | +--------------------------------------------------+ Figure 3: Outbound Route Filtering Capability Encoding Corrected Text -------------- Notes ----- RFC5291 does not specify how the ORF capability is supposed to be used in conjunction with multiple enabled AFI/SAFI combinations. The text can be interpreted as either "one capability instance will be sent, carrying multiple blocks as described in Figure 3" or as "the capability will be supplied in more than instance". Note also that RFC3392 [BGP-CAP] Section 4 reads: BGP speakers MAY include more than one instance of a capability (as identified by the Capability Code) with non-zero Capability Length field, but with different Capability Value, and either the same or different Capability Length. Processing of these capability instances is specific to the Capability Code and MUST be described in the document introducing the new capability. Latter description of how multiple instances of the capability are to be processed - albeit relatively obvious - is nowhere to be found in RFC5291. Respectfully requesting a clarification, David Lamparter 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. -------------------------------------- RFC5291 (draft-ietf-idr-route-filter-17) -------------------------------------- Title : Outbound Route Filtering Capability for BGP-4 Publication Date : August 2008 Author(s) : E. Chen, Y. Rekhter Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From rjs@rob.sh Mon Jan 28 10:49:27 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B613421F8718; Mon, 28 Jan 2013 10:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+QhgehDwQgc; Mon, 28 Jan 2013 10:49:26 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 158F321F8717; Mon, 28 Jan 2013 10:49:26 -0800 (PST) Received: from [217.41.232.50] (helo=[10.10.3.134]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1TztiP-0008Tq-LL; Mon, 28 Jan 2013 18:45:57 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <31774_1357642629_50EBFB84_31774_520_1_53C29892C857584299CBF5D05346208A122AFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Mon, 28 Jan 2013 18:49:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31774_1357642629_50EBFB84_31774_520_1_53C29892C857584299CBF5D05346208A122AFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: bruno.decraene@orange.com X-Mailer: Apple Mail (2.1499) Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 18:49:27 -0000 Hi Bruno, Thanks for the review of this version of the draft. I've added some = feedback in-line as [rjs]. My apologies for the delay in responding. On 8 Jan 2013, at 10:57, bruno.decraene@orange.com wrote: > 1) Critical error (=A73) > =20 > IMHO, the term =93critical error=94 is mixing both technical/protocol = considerations (e.g. can=92t read the update) and requirements = considerations (BGP sessions state is too degraded and I prefer shutting = it down rather than running on a degraded mode) which IMHO is = unfortunate and does not help the discussion. I=92d much prefer that we = distinguish both by defining technical levels of errors and then = defining the requirements for each plus the consequences/drawbacks of = the decision (whether to keep or shut the session). > For the protocol standpoint, I would propose the following level of = errors, based on the protocol encoding layers: session, update, = attribute. > - attribute level error: semantic or syntax error in the attribute = value or attribute flags > - session level error: error in the update length / marker. i.e. if = skipping the update length I can=92t find the marker of the next bgp = message. > - update level error: any other error in the update message > =20 > We can further distinguish if the NLRIs can be parsed or not. [rjs]: I would observe that there are two ways that we can consider how = to classify errors here -- one based on the definition of the impact on = the UPDATE of errors, and then one based on the reaction to those = errors. The current draft (clearly) takes the latter approach for = classification and reaction, however, as you say, it could be = advantageous to classify the significance of the error to determine how = "broken" the UPDATE is, and then map this to the possible approaches for = handling the error. [rjs]: If we were to take this approach -- then we could end up with a = mapping of errors of: - For attribute-level errors, if it is not the NLRI-carrying = attribute affected, then this is NLRI-level error handling, otherwise = use session level error handling. - For session-level errors, only use session-level error = handling. - For UPDATE-level errors, if the NLRI attribute can be parsed, = then use error handling targeted to the NLRI, else handle it at a = session level. I am not clear where we would have UPDATE errors that do not fall within = either the attribute, or session categories - do you have any example to = help me understand? Also, do you envisage cases where there are = session-level errors that we would map to any NLRI-level error handling? [rjs]: It does sound advantageous to note the caveats of holding the = session up for each type of error -- I will work to add a paragraph to =A7= 3 that describes the motivation for wanting to hold the session up in = some cases, and the drawbacks of doing so. > 2) Business Requirements > In the current text, I found the requirements a bit too technically = oriented. I=92d rather add business requirements independent of the = current solutions. I would propose: > =20 > In VPN networks, VPN are supposed to be isolated from each others and = from the others services (most notably the Internet). Hence, an error on = routes/BGP messages related to a VPN SHOULD NOT negatively impact others = VPN. Similarly, an error on routes/BGP messages related to a non VPN = service SHOULD not negatively impact the VPN service. > In Internet networks, ASes are supposed to be Autonomous. Hence an = error on routes/BGP messages originated by an AS SHOULD NOT negatively = impact destinations originated from others ASes. > =20 > By =93negatively impact=94, we mean losing reachability for a = destination (NLRI), typically by losing all the paths in the Loc-RIB to = that destination (NLRI). Note that those paths may be learnt through = multiple BGP sessions and hence the requirement span multiple BGP = sessions. The consequence is that if the BGP error is believed to be = limited to a single BGP session (e.g. a session level error), then in a = network with redundancy, the destination is believed to be still known = through another session and hence the session MAY be chosen to be = shutdown and all path learned from that session removed. On the = contrary, if the BGP error has a chance to be also met on the redundant = paths/sessions, then the BGP session and the routes learned from that = session SHOULD be preserved, until the negatives consequences are = considered too important. When evaluating those consequences, the fact = that all redundant paths/sessions may suffer from the same error and = hence will inherit the same decision MUST be considered. [rjs]: I will go through and review this section to try and align it = more with the service/business requirements for BGP deployments. It = strikes me that the suggestion above is more related to an additional = point that is not clearly included in this section around the different = requirements for differing networks in which BGP is deployed. I would = suggest that this is something that is added to the latter part of =A72, = and the existing text remains. I'm keen that we provide some background = as to *why* there is motivation for change in terms of deployment = characteristics, as well as covering the business requirements you = mention above. > =20 > As an illustration, we typically seek to avoid that because of a = single BGP error a PE lose both its redundant iBGP session with its BGP = RR. And by =93a PE=94 I really mean all PE experiencing this condition. = Could easily be 10s of PE, even 100s. > =20 > 3) Technical requirements > For session level error, the BGP session is dead so need to be = shutdown/graceful shutdown/graceful restart. If the update length is set = to the number of octets sent to the peer (or vice versa) rather than = computed based on the content of the update, there is a chance to 1) = limit the number of such session level errors and 2) increase the = probability that this error is local to that session and not likely to = happen on a redundant/backup session. There is probably a limited part = of the BGP code which needs to be hardened to reduce such unrecoverable = errors. And if those errors are still frequent, we may further propose = technical solutions (e.g. replacing TCP by SCTP which can provides = message boundaries, among others things (e.g. some benefits of = multi-sessions)) > =20 > For attribute & update level error when the NLRI can be parsed, cf = draft-error-handling (treat as withdraw). [rjs]: AIUI, if we added this requirement, then we could say that the = total UPDATE length should be trusted as the "real" length of the = transmitted UPDATE (which would be further validated by the subsequent = presence of the marker). In this case, (and I expect we are getting = towards draft-ietf-idr-error-handling here), then do you think that = there is a capability required to indicate that an implementation has = used this method of calculation? Without one, then we have the ambiguity = of whether an implementation used this "trick" and hence are not clear = whether we should trust it. > Now let the discussion begin J. For attribute & update level error = when the NLRI cannot be extracted IMHO there is room for discussion and = analysis of the consequences. > =20 > =93since the NLRI cannot be extracted, error handling mechanisms must = be applied at the per-session level=94 (=A75) > Well, IMO, this is a choice to be made rather than a =93must=94. [rjs]: Do you envisage that this is a requirement in all scenarios, or a = special case to be able to hold the session up following repeated = errors? If during normal operation one tries to apply treat-as-withdraw, = then this cannot be done (safely) unless we can determine to which NLRI = this should be applied to. I'm unclear whether this not being a MUST = (although at the moment it's a lower-case 'must') really implies that we = have a requirement for a solution akin to the persistence draft as a = "last resort" mechanism? [rjs]: I think that this in-line with your later discussion -- = essentially, the different levels as to how conservative one might want = to be are very black and white at the current time (within the draft), = as it's really whether you have these mechanisms "on", or "off". Is your = suggestion that we evaluate more levels of error handling (i.e., include = the "ignore all errors and continue operating") within this document, or = is it an evaluation between the current on/off levels? Extending the = draft to cover the "hold up" use case potentially expands it outside of = BGP error handling that is applicable to most deployments of BGP into = more special cases in my view. I'd like to understand whether the = working group feels that this problem space falls within the scope of = this draft. Thanks, r. > If we were to skip a BGP update: > For Internet, probably the worst case would be to miss a BGP update = with a loop in the AS path and hence create a loop for me and my = upstream ASes for the NLRI in the missed updated. How much probable is = this? 0 for iBGP sessions. TBE for eBGP. Then what would be the = consequences? loss of connectivity for the NLRI until the problem is = manually solved by an AS between the origin and me, possible forwarding = congestions for others. I=92m not sure I care too much about loosing = reachability to NLRI in faulty BGP update as most likely, if only one = BGP update (out of millions) is faulty, the reason may come from the = origin AS playing with a specific bit or attribute and if they chose to = play with their update, they should bear the responsibility. To be = compared by the probability of losing all redundant paths (if the error = is seen on redundant path) and the consequences (PE -possibly all PEs- = down). > =20 > For VPN, probably the worst case would be to keep a VPN label = previously allocated to VPN 1 and re-allocated to another VPN (VPN = breach Cf = http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01#section-8) > Again, the pro and con could be discussed (e.g. possibly one way = partial VPN breach for some time (that basically no one can exploit) vs = all VPN/PE being down. IMHO, if we believe such issue could be corrected = in 30-60 minutes, I would probably favor keeping the session up. > =20 > =46rom the lively discussions, looks like the opinions may vary = depending on the AS, people and circumstances. E.g. how much my = redundant BGP paths are failure independent? (e.g. use different BGP = implementations) > As such, what about defining severity levels for BGP error handling? = As one may wish to accept only low severity errors while others may be = willing to accept high severity errors (including when the NLRI cannot = be found) e.g. the network has been down for 30 minutes, while waiting = for the patch, one may want to be able to restore some service at all = costs (can=92t possibly be worst). > =20 > Again, IMHO it would be good to discuss the drawbacks depending on the = situation (iBGP, eBGP; hop by hop routed, tunneled =85) in this = requirement document to make sure we are all on the same page, we have = constructive discussions and SP enabling revised error handling are = fully aware of the consequences. > =20 > 4) Security consideration > In =A77 =93security considerations=94 I would discuss the fact that = current BGP error handling (or a (too) strict one) could be exploited by = attackers to create a remote DOS attack. > Should we also ask a review of the SIDR WG since =93The purpose of the = SIDR working group is to reduce vulnerabilities in the inter-domain = routing system.=94 ? ... > =20 > Best regards, > Bruno > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > >-----Original Message----- > >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Rob > >Shakir > >Sent: Thursday, December 27, 2012 7:44 PM > >To: idr@ietf.org > >Subject: [Idr] Fwd: [GROW] I-D Action: = draft-ietf-grow-ops-reqs-for-bgp-error- > >handling-06.txt > >=20 > >Hi IDR! > >=20 > >FYI -- please find an updated relating to a new version of = draft-ietf-grow-ops- > >reqs-for-bgp-error-handling. > >=20 > >Any comments very welcome (to me or grow@). > >=20 > >Seasons greetings! > >r. > >=20 > >Begin forwarded message: > >=20 > >> From: > >> Subject: Re: [GROW] I-D Action: = draft-ietf-grow-ops-reqs-for-bgp-error- > >handling-06.txt > >> Date: 27 December 2012 18:41:50 GMT > >> To: , > >> Cc: grow@ietf.org > >>=20 > >> On 27/12/2012 18:35, "internet-drafts@ietf.org" = > >> wrote: > >>=20 > >>>=20 > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> This draft is a work item of the Global Routing Operations Working = Group > >>> of the IETF. > >>>=20 > >>> Title : Operational Requirements for Enhanced Error = Handling > >>> Behaviour in BGP-4 > >>> Author(s) : Rob Shakir > >>> Filename : = draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt > >>> Pages : 19 > >>> Date : 2012-12-27 > >>=20 > >> Hi GROW! > >>=20 > >> This update is a fairly major re-spin of the BGP Error Handling > >> requirements draft. The technical content should be as per the = previous > >> revisions however, following the ietf/RtgDir last call comments, I = have > >> made the following changes: > >>=20 > >> * Made the amendments that were discussed and there was no = disagreement > >> with from our meeting in Atlanta -- this is essentially renaming = the > >> Critical/Semantic error types to Critical/Non-Critical. > >>=20 > >> * Significant de-duplication within the text including merging the > >> operational monitoring/toolset discussions into the error handling > >> sections. > >>=20 > >> * Adoption of rfc2119 language throughout to clarify the = requirements. > >>=20 > >> * Removal of some of the discussion around more detailed = justifications > >> for why particular decisions were made. I think this was useful = through > >> the discussion phase of this draft, but it seems like GROW/IDR have > >> converged on a relatively stable set of requirements, so I have = trimmed > >> back some of this discussion. > >>=20 > >> I'd really welcome any further comments on this before we re-submit = for > >> publication. To eke these out - Peter/Chris - can you kick off a = WGLC for > >> this draft please? :-) > >>=20 > >> Seasons greetings! > >> r. > >>=20 > >> _______________________________________________ > >> GROW mailing list > >> GROW@ietf.org > >> https://www.ietf.org/mailman/listinfo/grow > >=20 > >_______________________________________________ > >Idr mailing list > >Idr@ietf.org > >https://www.ietf.org/mailman/listinfo/idr > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 From farmer@umn.edu Mon Jan 28 12:34:02 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5B21F86A2 for ; Mon, 28 Jan 2013 12:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nj5aOA7Fto+Z for ; Mon, 28 Jan 2013 12:34:01 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 053FE21F8698 for ; Mon, 28 Jan 2013 12:34:00 -0800 (PST) Received: from mail-ie0-f197.google.com (mail-ie0-f197.google.com [209.85.223.197]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 28 Jan 2013 14:33:49 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f197.google.com [209.85.223.197] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f197.google.com with SMTP id 13so2845358iea.8 for ; Mon, 28 Jan 2013 12:33:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=hoSY47U9SqejwIexOBUeirt8PUH1KLUfT+bUxflMdN4=; b=PbojNHorBpKLT4zE87vPvjwD/zCcrdjDcsFwB85zVOteUj/aef37sxDRqpckliVTxe En7p8u5i1iL/3D29+N8Aoe4BPa0e4bj5pr2AwB3QLh6bAYVyflV9aIDM9nzHdOU5ZceC g9dPgl7jiro6Aa+dY816tjugN15BfhnlCLTqXKLEIILJXspECzwtDfbZeuweS6K0wm6R 0MW3+q2+Bpz+GajiQLd31yDLIyl7CBs2f5vPBhNkDFI/kTnDBqM66znYiIb3ki8uU+57 Se7CE1gHipOt1UV/paak7GV4E1VcmLCraGt1CBJ7dMnYhFBoRsQOxT59vgfktxlGKoS2 4CGg== X-Received: by 10.50.163.104 with SMTP id yh8mr5996378igb.112.1359405229397; Mon, 28 Jan 2013 12:33:49 -0800 (PST) X-Received: by 10.50.163.104 with SMTP id yh8mr5996374igb.112.1359405229323; Mon, 28 Jan 2013 12:33:49 -0800 (PST) Received: from x-134-84-88-75.nts.umn.edu (x-134-84-88-75.nts.umn.edu. [134.84.88.75]) by mx.google.com with ESMTPS id dc8sm7607121igb.15.2013.01.28.12.33.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 12:33:48 -0800 (PST) Message-ID: <5106E0AA.6090402@umn.edu> Date: Mon, 28 Jan 2013 14:33:46 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jakob Heitz References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net>, <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> In-Reply-To: <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlppU+IM9nQx8JHETggsRXDVNGtejrGbuAWP03MI32nFG/vMUbfZ9niCdlokRkEdfQSOYybtHBkG1LOAeK7+evEfGwiWFspW29zLCLxDW5EeuILStfNYJthyZwljwzAtcOyA5tc Cc: John Leslie , "John G. Scudder" , idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 20:34:02 -0000 On 1/8/13 13:51 , Jakob Heitz wrote: >> I agree we need to pick one approach or the other, and it should be either "MUST propagate as received", or "MUST propagate as zero". The SHOULD option is essentially what we have now and really won't fix the issue one way or the other. If we want to go the SHOULD route, I'd prefer we just add "When received, any value MUST be accepted" as a simple errata. >> >> I prefer the "MUST propagate as received" option personally. > > That would work if bgp were new. But it's not. > Anything other than "MUST propagate as zero" risks a session reset. I won't do that. > > -- > Jakob Heitz. I've been thinking about this issue for a bit, and would like to suggest a compromise; all implementations should provide "propagated as received" at least as an option and "propagate as zero" should be the only other allowed behavior. I propose something like the following text; SHOULD propagate as received. If not propagated as received, then MUST propagate as zero and provide a configuration option to propagate as received. This way all implementations are able to "propagate as received", it only becomes an issue of the default behavior an implementation chooses. With the recommended behavior being "propagate as received", and "propagate as zero" being the only other allowed behavior. There should also be additional discussion of the following; 1. As the "when received, any value MUST be accepted" clause is implemented more universally, implementations that choose "propagate as zero" as their default behavior should reconsider "propagate as received" as their default behavior. 2. That implementation that chose the recommended "propagate as received" should also consider a per-peer configuration option to "propagate as zero" for interoperability with older implementations that are known NOT to conform with the "when received, any value MUST be accepted" clause. This creates a knob, and I really don't like that, but honestly there are implementations that DO NOT conform with the "when received, any value MUST be accepted" clause, and we have to deal with, at least for now. So, while I think creating knobs should be avoided, I'm not sure it can realistically be avoided in this case, and with the implementations that are in the wild today. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From jsw@inconcepts.biz Mon Jan 28 17:03:47 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF27521E8055 for ; Mon, 28 Jan 2013 17:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKKI4rk4h1J9 for ; Mon, 28 Jan 2013 17:03:47 -0800 (PST) Received: from mail-ie0-x231.google.com (ie-in-x0231.1e100.net [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 42C2C21E8054 for ; Mon, 28 Jan 2013 17:03:47 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id 16so1317543iea.22 for ; Mon, 28 Jan 2013 17:03:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=iE/PRjn1Bn0fryol04tAYnfdhI7+lj5XQ69R8C83Z58=; b=MUH2+qh7ATE/TSNGgbgZqNnWCpgQonQkbD6J5XVWY4C/6YeUtAG65YD076Q17BVOuf sFD7lNsHGVE4foA40ysLhmsbyKJ00s/2Jy3RYaRdE7F3M7L7NHumznUfcTqxfss655X0 iui/T40t2tq4VPBNu+9ooG/j57itxSW+Air8UxCcHMeLPxp7b1z5V+1bzTXqzl5c7V8N OSIDXB4sdvbzw/kHAQeTdbu679vXa4oo+5DkVyHokzvNsppshAZg1bjVkgZNRfquEldB AHS4n1h+P/m9os9TNW9NbCyaB5hhOuTLnSgNpKD5GaLvdiicFCnGF78N4gwuusqKg07C nFSQ== MIME-Version: 1.0 X-Received: by 10.50.57.232 with SMTP id l8mr6319742igq.54.1359421426773; Mon, 28 Jan 2013 17:03:46 -0800 (PST) Received: by 10.50.128.170 with HTTP; Mon, 28 Jan 2013 17:03:46 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <5106E0AA.6090402@umn.edu> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> Date: Mon, 28 Jan 2013 20:03:46 -0500 Message-ID: From: Jeff Wheeler To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkp+HQubawHWUyRuJ4uGSGQDtreZBwNDOBtEY4Sy5hBi4d7vfzu3YKIHmsAjAL/BvE3MTfJ Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 01:03:47 -0000 On Mon, Jan 28, 2013 at 3:33 PM, David Farmer wrote: > This creates a knob, and I really don't like that, but honestly there are > implementations that DO NOT conform with the "when received, any value MUST > be accepted" clause, and we have to deal with, at least for now. So, while > I think creating knobs should be avoided, I'm not sure it can realistically > be avoided in this case, and with the implementations that are in the wild > today. I always like options/knobs but I doubt your suggestion will be popular. Why do you think propagate-as-received should be the default behavior? -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From farmer@umn.edu Mon Jan 28 17:30:54 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8521D21E8085 for ; Mon, 28 Jan 2013 17:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHWRsxMCa9tT for ; Mon, 28 Jan 2013 17:30:54 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id E2D2021E8064 for ; Mon, 28 Jan 2013 17:30:53 -0800 (PST) Received: from mail-ob0-f197.google.com (mail-ob0-f197.google.com [209.85.214.197]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 28 Jan 2013 19:30:53 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f197.google.com [209.85.214.197] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f197.google.com with SMTP id ta14so20167904obb.4 for ; Mon, 28 Jan 2013 17:30:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=yuaMF7Lv8g27USAFVSKWZpKUfYZne88Fg59+4Bxhe+8=; b=pkZpRN4rFgtQ13BKxlUV5RGjhAJDAxFByC/aqZ9Myfl7tal7vazGaaTN8LDVqz4LC9 FEDtxewkLo24j7plVfrBqjXIQ+84mxzi09m2TUD3tlkhZQfWA2n5p1CfzBrH9lPRP/vP EV7cjkFQSX+/isOHvDONMer7ZkcOJj5odD6fDEuPvvDTrWe1PsNqgrbkQCVtlGe03PhU +9nn0w+xP4vK1/5d0RuqOUmbP6Bp8cuzREhgJXSg+A9vDol2rUOp7k4WlltTtozig+gh 6p2JP6j2bmemNJlM49Z/O6eseFGmYSUpNrvK/atIrQ1xycRAUBhmIFrJLM4cKCQA9WrV X3kA== X-Received: by 10.50.150.239 with SMTP id ul15mr6352958igb.93.1359423052898; Mon, 28 Jan 2013 17:30:52 -0800 (PST) X-Received: by 10.50.150.239 with SMTP id ul15mr6352955igb.93.1359423052815; Mon, 28 Jan 2013 17:30:52 -0800 (PST) Received: from x-134-84-88-75.nts.umn.edu (x-134-84-88-75.nts.umn.edu. [134.84.88.75]) by mx.google.com with ESMTPS id ww6sm569580igb.2.2013.01.28.17.30.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 17:30:52 -0800 (PST) Message-ID: <5107264A.2020501@umn.edu> Date: Mon, 28 Jan 2013 19:30:50 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jeff Wheeler References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmyvtKsDkjWzFjYkBTlXl2gKOBGtCFv752Zp3TxBBu6G8uScUOS2LAc+DSvDqeXBNtIWgVi/gIR1DyaysuQTIWd7NaS+ChTvoOnh+wXE8ZqoIE455NwCO9h+ZmPeCXlC9pjgVRk Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 01:30:54 -0000 On 1/28/13 19:03 , Jeff Wheeler wrote: > On Mon, Jan 28, 2013 at 3:33 PM, David Farmer wrote: >> This creates a knob, and I really don't like that, but honestly there are >> implementations that DO NOT conform with the "when received, any value MUST >> be accepted" clause, and we have to deal with, at least for now. So, while >> I think creating knobs should be avoided, I'm not sure it can realistically >> be avoided in this case, and with the implementations that are in the wild >> today. > > I always like options/knobs but I doubt your suggestion will be popular. > > Why do you think propagate-as-received should be the default behavior? The argument is in the intro of the draft; The real issue is that reserved flags are only useful if there is some hope of someday using them for something. If implementations reset these flags on propagation, then a future revision to the BGP specification which introduces a new flag will not be able to propagate the new attribute flag end to end, since it would be very likely that some well-meaning intermediate router would zero on it. The effort to roll out implementations that transited the new flag would almost certainly be prohibitive. The compromise is require all conforming implementations to at least support propagate-as-received as an option. It doesn't completely eliminate the issue described in the intro, but at least there is still some minimal hope of being able to implement new flags some day. Especially, since it should be clear that propagate-as-zero is really just a transition, and maybe in some future revision it could be removed once any-value-MUST-be-accepted is more or less universally implemented. One can hope, at least I link that better than "the bits are dead". What do others think? -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From bruno.decraene@orange.com Tue Jan 29 03:11:48 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166FB21F87F3; Tue, 29 Jan 2013 03:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8yGamWhzrjh; Tue, 29 Jan 2013 03:11:46 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 03FD621F87DF; Tue, 29 Jan 2013 03:11:45 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A015B3242CB; Tue, 29 Jan 2013 12:11:44 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8344823804B; Tue, 29 Jan 2013 12:11:44 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 12:11:44 +0100 From: To: Rob Shakir Thread-Topic: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt Thread-Index: AQHN/YgyDXXczkGpk0WalTZDUDPs25hgBKBg Date: Tue, 29 Jan 2013 11:11:43 +0000 Message-ID: <9382_1359457904_5107AE70_9382_708_1_53C29892C857584299CBF5D05346208A12C433@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <31774_1357642629_50EBFB84_31774_520_1_53C29892C857584299CBF5D05346208A122AFB@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "idr@ietf.org" , "grow@ietf.org" Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 11:11:48 -0000 Hi Rob, Thanks for your reply. More inline. >From: Rob Shakir [mailto:rjs@rob.sh] >Sent: Monday, January 28, 2013 7:49 = PM > >Hi Bruno, > >Thanks for the review of this version of the draft. I've added some feedba= ck >in-line as [rjs]. My apologies for the delay in responding. > >On 8 Jan 2013, at 10:57, bruno.decraene@orange.com wrote: > >> 1) Critical error (=A73) >> >> IMHO, the term "critical error" is mixing both technical/protocol >considerations (e.g. can't read the update) and requirements considerations >(BGP sessions state is too degraded and I prefer shutting it down rather t= han >running on a degraded mode) which IMHO is unfortunate and does not help the >discussion. I'd much prefer that we distinguish both by defining technical >levels of errors and then defining the requirements for each plus the >consequences/drawbacks of the decision (whether to keep or shut the sessio= n). >> For the protocol standpoint, I would propose the following level of erro= rs, >based on the protocol encoding layers: session, update, attribute. >> - attribute level error: semantic or syntax error in the attribute value= or >attribute flags >> - session level error: error in the update length / marker. i.e. if skip= ping >the update length I can't find the marker of the next bgp message. >> - update level error: any other error in the update message >> >> We can further distinguish if the NLRIs can be parsed or not. > >[rjs]: I would observe that there are two ways that we can consider how to >classify errors here -- one based on the definition of the impact on the U= PDATE >of errors, and then one based on the reaction to those errors.=20 [Bruno]: Indeed, but the point of the draft is discussing the requirements = for those reactions, since we would like them to change. If you define, at the very beginning of the draft, which errors are "critic= al" and hence require a bgp session shut, then IMHO the discussion is close= d and the draft done after those lines. >The current >draft (clearly) takes the latter approach for classification and reaction, >however, as you say, it could be advantageous to classify the significance= of >the error to determine how "broken" the UPDATE is, and then map this to the >possible approaches for handling the error. > >[rjs]: If we were to take this approach -- then we could end up with a map= ping >of errors of: > - For attribute-level errors, if it is not the NLRI-carrying attribute >affected, then this is NLRI-level error handling, otherwise use session le= vel >error handling. > - For session-level errors, only use session-level error handling. > - For UPDATE-level errors, if the NLRI attribute can be parsed, then use >error handling targeted to the NLRI, else handle it at a session level. >I am not clear where we would have UPDATE errors that do not fall within e= ither >the attribute, or session categories - do you have any example to help me >understand?=20 [Bruno]:=20 - attribute-level error: the error is limited to an attribute (within a sin= gle attribute). Example: "attribute low bits flags" set - update-level error: I can't parse the next attributes in that update. Exa= mple: RIP labs incident. The error is more than a single attribute, however= the session could still survive as session level length was ok. >Also, do you envisage cases where there are session-level errors >that we would map to any NLRI-level error handling? [Bruno]: No. For session-level erros, I can't parse the current update nor = any subsequent data, including next update. >[rjs]: It does sound advantageous to note the caveats of holding the sessi= on up >for each type of error -- I will work to add a paragraph to =A7 3 that des= cribes >the motivation for wanting to hold the session up in some cases, and the >drawbacks of doing so. [Bruno]: Thank you. >> 2) Business Requirements >> In the current text, I found the requirements a bit too technically orie= nted. >I'd rather add business requirements independent of the current solutions.= I >would propose: >> >> In VPN networks, VPN are supposed to be isolated from each others and fr= om >the others services (most notably the Internet). Hence, an error on routes= /BGP >messages related to a VPN SHOULD NOT negatively impact others VPN. Similar= ly, >an error on routes/BGP messages related to a non VPN service SHOULD not >negatively impact the VPN service. >> In Internet networks, ASes are supposed to be Autonomous. Hence an error= on >routes/BGP messages originated by an AS SHOULD NOT negatively impact >destinations originated from others ASes. >> >> By "negatively impact", we mean losing reachability for a destination (N= LRI), >typically by losing all the paths in the Loc-RIB to that destination (NLRI= ). >Note that those paths may be learnt through multiple BGP sessions and henc= e the >requirement span multiple BGP sessions. The consequence is that if the BGP >error is believed to be limited to a single BGP session (e.g. a session le= vel >error), then in a network with redundancy, the destination is believed to = be >still known through another session and hence the session MAY be chosen to= be >shutdown and all path learned from that session removed. On the contrary, = if >the BGP error has a chance to be also met on the redundant paths/sessions,= then >the BGP session and the routes learned from that session SHOULD be preserv= ed, >until the negatives consequences are considered too important. When evalua= ting >those consequences, the fact that all redundant paths/sessions may suffer = from >the same error and hence will inherit the same decision MUST be considered. > >[rjs]: I will go through and review this section to try and align it more = with >the service/business requirements for BGP deployments. It strikes me that = the >suggestion above is more related to an additional point that is not clearly >included in this section around the different requirements for differing >networks in which BGP is deployed. I would suggest that this is something = that >is added to the latter part of =A72, and the existing text remains. I'm ke= en that >we provide some background as to *why* there is motivation for change in t= erms >of deployment characteristics, as well as covering the business requiremen= ts >you mention above. [Bruno]: "Why" is good. But I wish we could also clarify/discuss what our (= ultimate) goals/requirements are. Indeed, my proposition is service depende= nt. But the reality is that BGP is used for different services/business and= hence the business requirements are per service. The current draft is good, but other the time, most of its requirements are= now already covered with some proposed solution. Ideally, I'd like the doc= ument to also pave the road for the future and future solutions. IMHO, my above business requirements are reasonable, at least the VPN one. = But they are still not covered by existing proposed solutions, nor the requ= irement draft. Regarding the organization of the draft, I would leave it to you. I fine if this is added in the latter part of =A72. 2 comments: - IMHO, I would rename "2. Problem Statement" into "2. Introduction" and "2= .1. Role of BGP-4 in Service Provider Networks" into "3 Problem Statement".= And I would add the business requirements in last =A7. - at the end of current =A72.1: "This document defines a set of requirement= s for protocol developments" I would propose :s/requirements/technical req= uirements (to make the distinction between business requirements which=20 are in this =A7 and the technical requirements in the next. >> >> As an illustration, we typically seek to avoid that because of a single = BGP >error a PE lose both its redundant iBGP session with its BGP RR. And by "a= PE" >I really mean all PE experiencing this condition. Could easily be 10s of P= E, >even 100s. >> >> 3) Technical requirements >> For session level error, the BGP session is dead so need to be >shutdown/graceful shutdown/graceful restart. If the update length is set t= o the >number of octets sent to the peer (or vice versa) rather than computed bas= ed on >the content of the update, there is a chance to 1) limit the number of such >session level errors and 2) increase the probability that this error is lo= cal >to that session and not likely to happen on a redundant/backup session. Th= ere >is probably a limited part of the BGP code which needs to be hardened to r= educe >such unrecoverable errors. And if those errors are still frequent, we may >further propose technical solutions (e.g. replacing TCP by SCTP which can >provides message boundaries, among others things (e.g. some benefits of mu= lti- >sessions)) >> >> For attribute & update level error when the NLRI can be parsed, cf draft- >error-handling (treat as withdraw). > >[rjs]: AIUI, if we added this requirement, then we could say that the total >UPDATE length should be trusted as the "real" length of the transmitted UP= DATE >(which would be further validated by the subsequent presence of the marker= ).=20 [Bruno]: correct. With possibly :s/"real"/specified > In >this case, (and I expect we are getting towards draft-ietf-idr-error-handl= ing >here), then do you think that there is a capability required to indicate t= hat >an implementation has used this method of calculation? Without one, then we >have the ambiguity of whether an implementation used this "trick" and henc= e are >not clear whether we should trust it. [Bruno]: So far, IMO, I don't see a need for a capability. For the receiver: Update message length indicates where is located the next= update. We could see the marker as a check. Then either I can read the nex= t update or not. Seems within the existing BGP spec. No trick. For the sender: IMO clearly specifying that the receiver will use the updat= e message length as the message delimiter, will put emphasize on making thi= s field right (which seems doable to me as it's independent of the attribut= es within the message. That's just the number of byte that I'm sending) oth= erwise the session is dead. >> Now let the discussion begin J. For attribute & update level error when = the >NLRI cannot be extracted IMHO there is room for discussion and analysis of= the >consequences. >> >> "since the NLRI cannot be extracted, error handling mechanisms must be >applied at the per-session level" (=A75) >> Well, IMO, this is a choice to be made rather than a "must". > >[rjs]: Do you envisage that this is a requirement in all scenarios, or a >special case to be able to hold the session up following repeated errors? = If >during normal operation one tries to apply treat-as-withdraw, then this ca= nnot >be done (safely) unless we can determine to which NLRI this should be appl= ied >to.=20 [Bruno]: IMO if in some scenario, this tool is required to fulfill business requirem= ents, we should not forbid it. Possibly combined with other tools to make i= t safer. That being said, I don't believe we will do the full work (analysis & solut= ions) to address those business requirements. So let's start with a first p= hase, and then we'll see if this is enough or not. So I'm fine with keeping= the session up even if some NLRI cannot be parsed, only for special cases = manually enabled. > I'm unclear whether this not being a MUST (although at the moment it's a >lower-case 'must') really implies that we have a requirement for a solution >akin to the persistence draft as a "last resort" mechanism? To clarify, here I was referring to update level errors or MP attribute lev= el errors where NLRI cannot be extracted. The persistence draft would be for session level errors where the session c= annot be re-established.=20 >[rjs]: I think that this in-line with your later discussion -- essentially= , the >different levels as to how conservative one might want to be are very blac= k and >white at the current time (within the draft), as it's really whether you h= ave >these mechanisms "on", or "off". Is your suggestion that we evaluate more >levels of error handling (i.e., include the "ignore all errors and continue >operating") within this document,=20 [Bruno]: yes. My suggestion was that we evaluate, or at least not forbid an= d explicitly leave if for the future, other response to error condition. Sp= ecifically session "hold up" >or is it an evaluation between the current >on/off levels? Extending the draft to cover the "hold up" use case potenti= ally >expands it outside of BGP error handling that is applicable to most deploy= ments >of BGP into more special cases in my view.=20 [Bruno]: rather than "more special cases", I'd say "type of BGP errors not = yet widely faced" >I'd like to understand whether the >working group feels that this problem space falls within the scope of this >draft. [Bruno]: I believe that the error handling requirement should cover all cas= es, otherwise this means that we don't have requirements for other cases (o= k, more realistically, we don't want to bother thinking on hypothetical cas= es). But I'm fine with leaving this as a next phase. In which case, IMO the= draft should not close the door but rather hint for a possible next phase. Many thanks Rob. You picked a difficult work on a difficult subject. Bruno >Thanks, >r. > >> If we were to skip a BGP update: >> For Internet, probably the worst case would be to miss a BGP update with= a >loop in the AS path and hence create a loop for me and my upstream ASes fo= r the >NLRI in the missed updated. How much probable is this? 0 for iBGP sessions= . TBE >for eBGP. Then what would be the consequences? loss of connectivity for the >NLRI until the problem is manually solved by an AS between the origin and = me, >possible forwarding congestions for others. I'm not sure I care too much a= bout >loosing reachability to NLRI in faulty BGP update as most likely, if only = one >BGP update (out of millions) is faulty, the reason may come from the origi= n AS >playing with a specific bit or attribute and if they chose to play with th= eir >update, they should bear the responsibility. To be compared by the probabi= lity >of losing all redundant paths (if the error is seen on redundant path) and= the >consequences (PE -possibly all PEs- down). >> >> For VPN, probably the worst case would be to keep a VPN label previously >allocated to VPN 1 and re-allocated to another VPN (VPN breach Cf >http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01#section-8) >> Again, the pro and con could be discussed (e.g. possibly one way partial= VPN >breach for some time (that basically no one can exploit) vs all VPN/PE bei= ng >down. IMHO, if we believe such issue could be corrected in 30-60 minutes, I >would probably favor keeping the session up. >> >> From the lively discussions, looks like the opinions may vary depending = on >the AS, people and circumstances. E.g. how much my redundant BGP paths are >failure independent? (e.g. use different BGP implementations) >> As such, what about defining severity levels for BGP error handling? As = one >may wish to accept only low severity errors while others may be willing to >accept high severity errors (including when the NLRI cannot be found) e.g.= the >network has been down for 30 minutes, while waiting for the patch, one may= want >to be able to restore some service at all costs (can't possibly be worst). >> >> Again, IMHO it would be good to discuss the drawbacks depending on the >situation (iBGP, eBGP; hop by hop routed, tunneled .) in this requirement >document to make sure we are all on the same page, we have constructive >discussions and SP enabling revised error handling are fully aware of the >consequences. >> >> 4) Security consideration >> In =A77 "security considerations" I would discuss the fact that current = BGP >error handling (or a (too) strict one) could be exploited by attackers to >create a remote DOS attack. >> Should we also ask a review of the SIDR WG since "The purpose of the SIDR >working group is to reduce vulnerabilities in the inter-domain routing sys= tem." >? ... >> >> Best regards, >> Bruno >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >-----Original Message----- >> >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of R= ob >> >Shakir >> >Sent: Thursday, December 27, 2012 7:44 PM >> >To: idr@ietf.org >> >Subject: [Idr] Fwd: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- >error- >> >handling-06.txt >> > >> >Hi IDR! >> > >> >FYI -- please find an updated relating to a new version of draft-ietf-g= row- >ops- >> >reqs-for-bgp-error-handling. >> > >> >Any comments very welcome (to me or grow@). >> > >> >Seasons greetings! >> >r. >> > >> >Begin forwarded message: >> > >> >> From: >> >> Subject: Re: [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-erro= r- >> >handling-06.txt >> >> Date: 27 December 2012 18:41:50 GMT >> >> To: , >> >> Cc: grow@ietf.org >> >> >> >> On 27/12/2012 18:35, "internet-drafts@ietf.org" >> >> wrote: >> >> >> >>> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> >>> directories. >> >>> This draft is a work item of the Global Routing Operations Working G= roup >> >>> of the IETF. >> >>> >> >>> Title : Operational Requirements for Enhanced Error Hand= ling >> >>> Behaviour in BGP-4 >> >>> Author(s) : Rob Shakir >> >>> Filename : draft-ietf-grow-ops-reqs-for-bgp-error-handling- >06.txt >> >>> Pages : 19 >> >>> Date : 2012-12-27 >> >> >> >> Hi GROW! >> >> >> >> This update is a fairly major re-spin of the BGP Error Handling >> >> requirements draft. The technical content should be as per the previo= us >> >> revisions however, following the ietf/RtgDir last call comments, I ha= ve >> >> made the following changes: >> >> >> >> * Made the amendments that were discussed and there was no disagreeme= nt >> >> with from our meeting in Atlanta -- this is essentially renaming the >> >> Critical/Semantic error types to Critical/Non-Critical. >> >> >> >> * Significant de-duplication within the text including merging the >> >> operational monitoring/toolset discussions into the error handling >> >> sections. >> >> >> >> * Adoption of rfc2119 language throughout to clarify the requirements. >> >> >> >> * Removal of some of the discussion around more detailed justificatio= ns >> >> for why particular decisions were made. I think this was useful throu= gh >> >> the discussion phase of this draft, but it seems like GROW/IDR have >> >> converged on a relatively stable set of requirements, so I have trimm= ed >> >> back some of this discussion. >> >> >> >> I'd really welcome any further comments on this before we re-submit f= or >> >> publication. To eke these out - Peter/Chris - can you kick off a WGLC= for >> >> this draft please? :-) >> >> >> >> Seasons greetings! >> >> r. >> >> >> >> _______________________________________________ >> >> GROW mailing list >> >> GROW@ietf.org >> >> https://www.ietf.org/mailman/listinfo/grow >> > >> >_______________________________________________ >> >Idr mailing list >> >Idr@ietf.org >> >https://www.ietf.org/mailman/listinfo/idr >> >__________________________________________________________________________= _____ >__________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu >ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >> France Telecom - Orange decline toute responsabilite si ce message a ete >altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete >this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages >that have been modified, changed or falsified. >> Thank you. >> ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you.