From nobody Wed May 7 08:12:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422451A08A7 for ; Wed, 7 May 2014 08:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2m46SRNkkMp for ; Wed, 7 May 2014 08:12:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id A3B221A08AA for ; Wed, 7 May 2014 08:12:23 -0700 (PDT) Received: from rmurpher-sslvpn-nc.jnpr.net (66.129.241.13) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 7 May 2014 15:12:13 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <20140415143618.8E1591801A3@rfc-editor.org> Date: Wed, 7 May 2014 11:12:01 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7176992A-CE2F-45E1-8C27-E61465E55A50@juniper.net> References: <20140415143618.8E1591801A3@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BLUPR01CA018.prod.exchangelabs.com (10.141.30.48) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Forefront-PRVS: 0204F0BDE2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(164054003)(199002)(189002)(51704005)(24454002)(377454003)(88136002)(15188155005)(50466002)(76482001)(87976001)(100916002)(19580395003)(101416001)(42186004)(2009001)(97756001)(20776003)(87286001)(47776003)(50226001)(19580405001)(23726002)(79102001)(53416003)(77156001)(83716003)(4396001)(99396002)(16799955002)(36756003)(62966002)(46102001)(81542001)(46406003)(15975445006)(93916002)(86362001)(82746002)(57306001)(81342001)(15202345003)(77982001)(31966008)(92726001)(92566001)(76176999)(83322001)(33656001)(80022001)(85852003)(74502001)(83072002)(50986999)(74662001)(89996001)(66066001)(42262001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB722; H:rmurpher-sslvpn-nc.jnpr.net; FPR:EE5FD125.ACE2922A.73D35E03.CAD47B5D.20392; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Juy5utisWhKkSy4utm4-1V8dncQ Cc: "idr@ietf. org" , guban@microsoft.com, govindan@isi.edu, Ravi Chandra , Hares Susan Subject: Re: [Idr] [Technical Errata Reported] RFC2439 (3964) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:12:27 -0000 Hi Gunjan, RFC 2439 isn't the easiest to read, but according to my reading this = erratum is not correct. Despite its name, the "reuse list" as described = in S. 4.8.7 is used for processing timer-driven events in general, = including freeing up damping structures ("histories"). Quoting from S. = 4.8.7, "Handling Reuse Timer Events":=20 all of the routes in the first queue will be available for immediate reuse if reachable or the history entry could ^^^^^^^^^^^^^^^^^^^^^^^^^^ be disposed of if unreachable. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you have any doubt that "history" means "damping structure", take a = look at S. 4.8.2: If there is no previous stability history (the damping structure pointer is zero), then: I assume you're clear on why histories for unreachable routes need to be = maintained to begin with. I'm going to recommend to the AD that this erratum be rejected, unless = you or someone else wants to make a case why it shouldn't be. Thanks, --John On Apr 15, 2014, at 10:36 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC2439, > "BGP Route Flap Damping". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D2439&eid=3D3964 >=20 > -------------------------------------- > Type: Technical > Reported by: Gunjan Bansal >=20 > Section: 4.8.2 >=20 > Original Text > ------------- > In either case then: >=20 > 1. set t-updated =3D t-now >=20 > 2. insert into a reuse list (see Section 4.8.6) >=20 > Corrected Text > -------------- > In either case then: >=20 > 1. set t-updated =3D t-now >=20 >=20 > Notes > ----- > The route which is unreachable should NOT be inserted into the = reuse-list. reuse-list (as per explanation in Section 4.8.7) is used for = fast evaluation of routes which have been suppressed long enough and can = be potentially used again. The "unreachability/withdrawal" of route is = never suppressed and never needs to be re-evaluated in future. >=20 > 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.=20 >=20 > -------------------------------------- > RFC2439 (no draft string recorded) > -------------------------------------- > Title : BGP Route Flap Damping > Publication Date : November 1998 > Author(s) : C. Villamizar, R. Chandra, R. Govindan > Category : PROPOSED STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 >=20 From nobody Wed May 7 09:29:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F141A082F; Wed, 7 May 2014 09:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97kNUDUU8svw; Wed, 7 May 2014 09:29:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 35DD71A0828; Wed, 7 May 2014 09:29:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6E4BD18000F; Wed, 7 May 2014 09:28:31 -0700 (PDT) To: guban@microsoft.com, curtis@ans.net, rchandra@cisco.com, govindan@isi.edu X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140507162831.6E4BD18000F@rfc-editor.org> Date: Wed, 7 May 2014 09:28:31 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/kvKwAp5jC1kIoMXVqXCGz-v-Lj8 Cc: idr@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Errata Rejected] RFC2439 (3964) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 16:29:12 -0000 The following errata report has been rejected for RFC2439, "BGP Route Flap Damping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2439&eid=3964 -------------------------------------- Status: Rejected Type: Technical Reported by: Gunjan Bansal Date Reported: 2014-04-15 Rejected by: Alia Atlas (IESG) Section: 4.8.2 Original Text ------------- In either case then: 1. set t-updated = t-now 2. insert into a reuse list (see Section 4.8.6) Corrected Text -------------- In either case then: 1. set t-updated = t-now Notes ----- The route which is unreachable should NOT be inserted into the reuse-list. reuse-list (as per explanation in Section 4.8.7) is used for fast evaluation of routes which have been suppressed long enough and can be potentially used again. The "unreachability/withdrawal" of route is never suppressed and never needs to be re-evaluated in future. --VERIFIER NOTES-- RFC 2439 isn't the easiest to read, but this erratum is not correct. Despite its name, the "reuse list" as described in S. 4.8.7 is used for processing timer-driven events in general, including freeing up damping structures ("histories"). Quoting from S. 4.8.7, "Handling Reuse Timer Events": all of the routes in the first queue will be available for immediate reuse if reachable or the history entry could ^^^^^^^^^^^^^^^^^^^^^^^^^^ be disposed of if unreachable. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you have any doubt that "history" means "damping structure", take a look at S. 4.8.2: If there is no previous stability history (the damping structure pointer is zero), then: Presumably, you're clear on why histories for unreachable routes need to be maintained to begin with. -------------------------------------- RFC2439 (no draft string recorded) -------------------------------------- Title : BGP Route Flap Damping Publication Date : November 1998 Author(s) : C. Villamizar, R. Chandra, R. Govindan Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed May 7 11:08:54 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62A01A01AE; Wed, 7 May 2014 11:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaNaaBv2libX; Wed, 7 May 2014 11:08:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C211A0207; Wed, 7 May 2014 11:08:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140507180846.28346.38054.idtracker@ietfa.amsl.com> Date: Wed, 07 May 2014 11:08:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/yGM6bvRzyYnuDj8z8GL4OMrinvs Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 18:08:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Revised Error Handling for BGP UPDATE Messages Authors : Enke Chen Juniper Networks Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-07.txt Pages : 13 Date : 2014-05-07 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, and 5701. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 7 11:17:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E971A0268 for ; Wed, 7 May 2014 11:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGuToSuA4FyW for ; Wed, 7 May 2014 11:17:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id 23EA61A037D for ; Wed, 7 May 2014 11:17:35 -0700 (PDT) Received: from rmurpher-sslvpn-nc.jnpr.net (66.129.241.13) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 7 May 2014 18:17:30 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <20140507180846.28346.38054.idtracker@ietfa.amsl.com> Date: Wed, 7 May 2014 14:17:23 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140507180846.28346.38054.idtracker@ietfa.amsl.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: DM2PR08CA010.namprd08.prod.outlook.com (10.141.52.168) To BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) X-Forefront-PRVS: 0204F0BDE2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(189002)(199002)(164054003)(377454003)(377424004)(51704005)(31966008)(101416001)(15202345003)(19580405001)(92566001)(15975445006)(89996001)(74662001)(79102001)(2009001)(80022001)(77982001)(86362001)(93916002)(76176999)(100916002)(69596002)(74502001)(85852003)(21056001)(83072002)(23726002)(82746002)(92726001)(83322001)(50466002)(20776003)(19580395003)(53416003)(97756001)(87286001)(36756003)(62966002)(46406003)(33656001)(81342001)(50226001)(87976001)(76482001)(42186004)(81542001)(77156001)(64706001)(4396001)(83716003)(47776003)(66066001)(99396002)(88136002)(81156002)(46102001)(50986999)(57306001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB725; H:rmurpher-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/1c7lcUyHH4aJpaHFreiNpJtz88M Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 18:17:38 -0000 Folks, Compared to -06, this version lists a couple more NLRI (in)correctness = criteria in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 on = the handling of typed NLRI (such as for MVPN and EVPN), makes an = editorial clarification regarding when a session must be reset, and = removes Appendix A. The deletion of Appendix A was because it was there = for purposes of explanation in the early versions of the draft, but at = this point everyone seems to get the point and there doesn't seem to be = any need to clutter up the eventual RFC with it.=20 With this revision the authors think the document is ready for working = group last call. Thanks, --John On May 7, 2014, at 2:08 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Inter-Domain Routing Working Group of = the IETF. >=20 > Title : Revised Error Handling for BGP UPDATE = Messages > Authors : Enke Chen > Juniper Networks > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-07.txt > Pages : 13 > Date : 2014-05-07 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not = only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. >=20 > This document updates error handling for RFCs 1997, 4271, 4360, = 4456, > 4760, and 5701. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 7 11:31:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F011A0269 for ; Wed, 7 May 2014 11:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPW6YubWK9sx for ; Wed, 7 May 2014 11:31:25 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B8ADB1A01C1 for ; Wed, 7 May 2014 11:31:24 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=216.54.92.2; From: "Susan Hares" To: "'John G. Scudder'" , "'idr@ietf. org'" Date: Wed, 7 May 2014 14:31:15 -0400 Message-ID: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9qIcSDkmbbyvO6RoGDqFwdKrtKLg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NOpC98J_yEX1w5yd_CfWhBO9pzQ Subject: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 18:31:26 -0000 John: Congratulations on publishing draft of draft-ietf-idr-error-handling-07.txt. This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. In your comments please indicate, support/no support for the WG LC. Please also indicate if you know if IPR by responding. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Wednesday, May 07, 2014 2:17 PM To: idr@ietf. org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt Folks, Compared to -06, this version lists a couple more NLRI (in)correctness criteria in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 on the handling of typed NLRI (such as for MVPN and EVPN), makes an editorial clarification regarding when a session must be reset, and removes Appendix A. The deletion of Appendix A was because it was there for purposes of explanation in the early versions of the draft, but at this point everyone seems to get the point and there doesn't seem to be any need to clutter up the eventual RFC with it. With this revision the authors think the document is ready for working group last call. Thanks, --John On May 7, 2014, at 2:08 PM, 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 Inter-Domain Routing Working Group of the IETF. > > Title : Revised Error Handling for BGP UPDATE Messages > Authors : Enke Chen > Juniper Networks > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-07.txt > Pages : 13 > Date : 2014-05-07 > > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. > > This document updates error handling for RFCs 1997, 4271, 4360, 4456, > 4760, and 5701. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-07 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 7 11:32:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7461A0269 for ; Wed, 7 May 2014 11:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nluifziRcBLL for ; Wed, 7 May 2014 11:32:51 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C1CC41A01C1 for ; Wed, 7 May 2014 11:32:51 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B0855C1FA; Wed, 7 May 2014 14:32:47 -0400 (EDT) Date: Wed, 7 May 2014 14:32:47 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20140507183247.GE17758@pfrc> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/FfbRzycg6YHEhwA46hT32Z-R59w Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 18:32:53 -0000 Sue, On Wed, May 07, 2014 at 02:31:15PM -0400, Susan Hares wrote: > Congratulations on publishing draft of draft-ietf-idr-error-handling-07.txt. > This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. In > your comments please indicate, support/no support for the WG LC. > > Please also indicate if you know if IPR by responding. While an implementation report would be more appropriate, might I also suggest asking in the poll whether you have an implementation covering the functionality? -- Jeff (who will be responding a qualified yes) From nobody Wed May 7 11:35:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8FB1A07CC for ; Wed, 7 May 2014 11:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_7-A-T5cagQ for ; Wed, 7 May 2014 11:35:45 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7651A01CE for ; Wed, 7 May 2014 11:35:45 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=216.54.92.2; From: "Susan Hares" To: "'Jeffrey Haas'" , References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20140507183247.GE17758@pfrc> In-Reply-To: <20140507183247.GE17758@pfrc> Date: Wed, 7 May 2014 14:35:37 -0400 Message-ID: <008d01cf6a23$242a5f30$6c7f1d90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGj8fXud1vrpGiTRuOtdk5WCitkjwI2K4skm3qwgUA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rq16WzC3_ag0jkqRr2mNtpWH3XI Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 18:35:46 -0000 IDR folks: Please do comment if you know about implementations. IDR does require 2 implementation for passing a draft to the IESG. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, May 07, 2014 2:33 PM To: idr@ietf.org Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Sue, On Wed, May 07, 2014 at 02:31:15PM -0400, Susan Hares wrote: > Congratulations on publishing draft of draft-ietf-idr-error-handling-07.txt. > This begins a 2 week WG LC starting today (5/7/14), and ending > 5/21/14. In your comments please indicate, support/no support for the WG LC. > > Please also indicate if you know if IPR by responding. While an implementation report would be more appropriate, might I also suggest asking in the poll whether you have an implementation covering the functionality? -- Jeff (who will be responding a qualified yes) _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 7 12:18:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D47B1A07B9 for ; Wed, 7 May 2014 12:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXm69TVpmpKR for ; Wed, 7 May 2014 12:18:06 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 36CC31A0843 for ; Wed, 7 May 2014 12:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1476; q=dns/txt; s=iport; t=1399490271; x=1400699871; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pxBvHW1PG+vu6owspNWi15817PsXvaMihTvRC+ig6YM=; b=AG5EEgvtmebSULCuLYwdfU5wEWu9cp6GREjiAqxPOxqFFBU/gQXIyreR ruxVZAiyHNdWNd/9UFaTuvYA4AtTpZcGkmCAEyxMIuIEkolFbBbgkuj+n SkU2w/EoNxUs9Co1qIh5JxEYBtB6m3+h5xADQgkJfbILUgJzNXbKZOkj/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAMmFalOtJV2Y/2dsb2JhbABagwZPWL1jhzwBgRwWdIIlAQEBBAEBATc0FwQCAQgOAwQBAQEeCQcnCxQJCAEBBAESiEEN0A8TBI5ZBoQ5AQOZN5J7gzSCLw X-IronPort-AV: E=Sophos;i="4.97,1005,1389744000"; d="scan'208";a="320080560" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 07 May 2014 19:17:50 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s47JHorc032027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 19:17:50 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.105]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 7 May 2014 14:17:49 -0500 From: "Saikat Ray (sairay)" To: Susan Hares , "'Jeffrey Haas'" , "idr@ietf.org" Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: Ac9qIcSDkmbbyvO6RoGDqFwdKrtKLgAKuKOAAAAZVYD//5ZxgA== Date: Wed, 7 May 2014 19:17:49 +0000 Message-ID: References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20140507183247.GE17758@pfrc> <008d01cf6a23$242a5f30$6c7f1d90$@ndzh.com> In-Reply-To: <008d01cf6a23$242a5f30$6c7f1d90$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [128.107.165.100] Content-Type: text/plain; charset="us-ascii" Content-ID: <8FECDA83AC6AC143B0D56ED469B421D0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HGt0Wby4z3LY-fSb31NHFs-W884 Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 19:18:07 -0000 Cisco IOS and XR OSes have implemeneted the error handling draft. The implementations are more than an year old, so not everything may be per -07, though. On 5/7/14, 11:35 AM, "Susan Hares" wrote: >IDR folks:=20 > >Please do comment if you know about implementations. IDR does require 2 >implementation for passing a draft to the IESG. > >Sue=20 > >-----Original Message----- >From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas >Sent: Wednesday, May 07, 2014 2:33 PM >To: idr@ietf.org >Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt > >Sue, > >On Wed, May 07, 2014 at 02:31:15PM -0400, Susan Hares wrote: >> Congratulations on publishing draft of >draft-ietf-idr-error-handling-07.txt. >> This begins a 2 week WG LC starting today (5/7/14), and ending >> 5/21/14. In your comments please indicate, support/no support for the >>WG >LC. >>=20 >> Please also indicate if you know if IPR by responding. > >While an implementation report would be more appropriate, might I also >suggest asking in the poll whether you have an implementation covering the >functionality? > >-- Jeff (who will be responding a qualified yes) > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 7 12:55:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BD41A0381 for ; Wed, 7 May 2014 12:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gqn8G_OV7sJ for ; Wed, 7 May 2014 12:55:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCDE1A0366 for ; Wed, 7 May 2014 12:55:02 -0700 (PDT) Received: from rmurpher-sslvpn-nc.jnpr.net (66.129.241.13) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 7 May 2014 19:54:56 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: Date: Wed, 7 May 2014 15:54:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <10E9D70B-1DCF-4037-BD90-192032B70427@juniper.net> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20140507183247.GE17758@pfrc> <008d01cf6a23$242a5f30$6c7f1d90$@ndzh.com> To: "Saikat Ray (sairay)" X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: DM2PR06CA006.namprd06.prod.outlook.com (10.141.96.36) To BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) X-Forefront-PRVS: 0204F0BDE2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(189002)(199002)(24454002)(50226001)(87976001)(46406003)(33656001)(81342001)(81542001)(77156001)(76482001)(42186004)(36756003)(97756001)(87286001)(62966002)(88136002)(81156002)(50986999)(46102001)(83716003)(4396001)(64706001)(99396002)(47776003)(66066001)(80022001)(2009001)(93916002)(77982001)(86362001)(76176999)(101416001)(31966008)(89996001)(92566001)(79102001)(74662001)(19580405001)(20776003)(19580395003)(53416003)(74502001)(21056001)(85852003)(23726002)(82746002)(100916002)(69596002)(83072002)(50466002)(83322001)(92726001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB725; H:rmurpher-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/FrQyZnTEpLoZ0eUKQVHansJ-CBk Cc: "idr@ietf.org" , Hares Susan Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 19:55:04 -0000 On May 7, 2014, at 3:17 PM, Saikat Ray (sairay) = wrote: > not everything may be per -07, though. I suspect many/most [*] will need to update their implementations since = -06 introduced one significant change (got rid of "fixing" the attribute = flags). It still seemed worth WGLC'ing since we now have the 'waiting for = implementation' state we can park the draft in for the (hopefully not = very long) interval until the implementations are updated. --John [*] Except Thomas Mangin who probably had his done 24 hours prior to = publication of -06 ;-)= From nobody Wed May 7 12:55:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52041A03A6 for ; Wed, 7 May 2014 12:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBU5dvnFetP3 for ; Wed, 7 May 2014 12:55:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id 237C41A03A4 for ; Wed, 7 May 2014 12:55:24 -0700 (PDT) Received: from rmurpher-sslvpn-nc.jnpr.net (66.129.241.13) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.934.12; Wed, 7 May 2014 19:55:19 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> Date: Wed, 7 May 2014 15:55:18 -0400 Content-Transfer-Encoding: 7bit Message-ID: <9F2CC5C2-FE5A-4585-8DD3-B412B2180150@juniper.net> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> To: Hares Susan X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: DM2PR06CA006.namprd06.prod.outlook.com (10.141.96.36) To BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) X-Forefront-PRVS: 0204F0BDE2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(189002)(199002)(164054003)(24454002)(50226001)(87976001)(46406003)(33656001)(81342001)(81542001)(77156001)(76482001)(42186004)(36756003)(97756001)(87286001)(62966002)(88136002)(81156002)(50986999)(46102001)(83716003)(4396001)(64706001)(99396002)(47776003)(66066001)(80022001)(2009001)(558084003)(93916002)(77982001)(86362001)(76176999)(101416001)(31966008)(89996001)(92566001)(79102001)(74662001)(19580405001)(20776003)(19580395003)(53416003)(74502001)(21056001)(85852003)(23726002)(82746002)(100916002)(69596002)(83072002)(50466002)(83322001)(92726001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB725; H:rmurpher-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/lo1veWRXX-dCZGtU89TCbBYzXuk Cc: "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 19:55:26 -0000 On May 7, 2014, at 2:31 PM, Susan Hares wrote: > Please also indicate if you know if IPR by responding. I am not aware of IPR related to this draft. Thanks, --John From nobody Wed May 7 13:22:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46F61A0398 for ; Wed, 7 May 2014 13:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heQuBG5-WRba for ; Wed, 7 May 2014 13:22:21 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA221A038E for ; Wed, 7 May 2014 13:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=464; q=dns/txt; s=iport; t=1399494137; x=1400703737; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bV5cddpFTre+vA/Jo9B4l361a72EM6BGS/QtOo6a9oQ=; b=N+0ajodVo3x2D/5HZ7iqk3MEUm3VGKl+tIrXU3OWZsVc5ecEoHRCQimt GZ8Wa/p6LFMyRWN4wvLKblsitFCfkjzPaaSGz6cFqnYr7Ll2Mh1Xd6Nqp AG0XWUUR7QLkNEdq7+UPn52ouRK/ssOba0t0n8lPUshprMsax9DlPsdBc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFALuValOrRDoI/2dsb2JhbABagwZPvjuHPAGBHRZ0giUBAQEEAQEBNTYLEAsYCSUPAhYwBgEMAQUCAQGIPA7QERMEjlIHhD8BA4oIjy+GZYwWg1Qd X-IronPort-AV: E=Sophos;i="4.97,1006,1389744000"; d="scan'208";a="112161904" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 07 May 2014 20:22:17 +0000 Received: from [10.154.165.239] ([10.154.165.239]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s47KMGhh001186; Wed, 7 May 2014 20:22:16 GMT Message-ID: <536A95F8.90604@cisco.com> Date: Wed, 07 May 2014 13:22:16 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "John G. Scudder" , Hares Susan References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <9F2CC5C2-FE5A-4585-8DD3-B412B2180150@juniper.net> In-Reply-To: <9F2CC5C2-FE5A-4585-8DD3-B412B2180150@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_21a5LyrdW46GmzJKQEqLrYPXRE Cc: "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 20:22:23 -0000 I am not aware of any IPRs related to this draft either. Thanks. -- Enke On 5/7/14 12:55 PM, John G. Scudder wrote: > On May 7, 2014, at 2:31 PM, Susan Hares wrote: > >> Please also indicate if you know if IPR by responding. > I am not aware of IPR related to this draft. > > Thanks, > > --John > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 7 13:44:13 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DF81A02F6 for ; Wed, 7 May 2014 13:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6ugrUOmmG15 for ; Wed, 7 May 2014 13:44:11 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6FD1A01C0 for ; Wed, 7 May 2014 13:44:11 -0700 (PDT) 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 s47Ki6Yn028372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2014 14:44:07 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 5811F1E005D; Wed, 7 May 2014 15:44:01 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 16C9D1E0049; Wed, 7 May 2014 15:44:01 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s47Ki0OH023992; Wed, 7 May 2014 14:44:00 -0600 (MDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s47KhxmH023973 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 14:44:00 -0600 (MDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.03.0158.001; Wed, 7 May 2014 14:43:59 -0600 From: "Smith, Donald" To: "John G. Scudder" , Hares Susan Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: Ac9qIcSDkmbbyvO6RoGDqFwdKrtKLgAPstYA//+oiFM= Date: Wed, 7 May 2014 20:43:59 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D12488647@PDDCWMBXEX503.ctl.intranet> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com>, <9F2CC5C2-FE5A-4585-8DD3-B412B2180150@juniper.net> In-Reply-To: <9F2CC5C2-FE5A-4585-8DD3-B412B2180150@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/VVHDKBP498ceIpI80x6Um9yC470 Cc: "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 20:44:12 -0000 The error handling of the following case described in Section 6.3 of [RFC4271] is revised If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the Error Subcode MUST be set to Attribute Flags Error. The Data field MUST contain the erroneous attribute (type, length, and value). as follows: If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the attribute MUST be treated as malformed and the treat-as-withdraw approach (see below) used, unless the specification for the attribute mandates different handling for incorrect Attribute Flags. Are there specifications for attributes that mandates different behavior or= is that a future looking statement? (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com= From nobody Wed May 7 14:29:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843B71A0398 for ; Wed, 7 May 2014 14:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4ZAsIYRhOjG for ; Wed, 7 May 2014 14:29:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF901A0362 for ; Wed, 7 May 2014 14:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=701; q=dns/txt; s=iport; t=1399498184; x=1400707784; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=L7kY1S+7PCIFQG1+1Lhw/pWT7SbWkspIKTIywgeEfMU=; b=edCISgmTGpjehbbqGY3tPXT7pe7ZehbWsUkYYxx/oqPcPejl6wpclGqh 0zw9T/GTsQAGYX6rLQ2swpiXYC7+NJ4yxzhr26WTX3T4lQU1PPLZJdwmT cUnydbR3ICvzcU0uOFTwOL0JQNRdET5nfVey1KfnrqObS5Phf4JznHw0P 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0IAG+lalOtJV2b/2dsb2JhbABagwZPWKsLBQGSUoc8AYEcFnSCJQEBAQQBAQE3NAsSAQgYHjcLJQIEAQ0FiEEN0A4TBIVWiHwHhD8BA5k3knuDNIIv X-IronPort-AV: E=Sophos;i="4.97,1006,1389744000"; d="scan'208";a="320109393" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 07 May 2014 21:29:42 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s47LTfFm022683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 21:29:41 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.14]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 7 May 2014 16:29:40 -0500 From: "Keyur Patel (keyupate)" To: "Enke Chen (enkechen)" , "John G. Scudder" , Hares Susan Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: AQHPajtzYmR4OXtq3kS5BKbqBUsyRQ== Date: Wed, 7 May 2014 21:29:39 +0000 Message-ID: In-Reply-To: <536A95F8.90604@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.156.0.132] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/4r3Qc4ckb9rJn9yXBi-jwzEclsU Cc: "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 21:29:47 -0000 +1. Regards, Keyur On 5/7/14 1:22 PM, "Enke Chen" wrote: >I am not aware of any IPRs related to this draft either. > >Thanks. -- Enke > >On 5/7/14 12:55 PM, John G. Scudder wrote: >> On May 7, 2014, at 2:31 PM, Susan Hares wrote: >> >>> Please also indicate if you know if IPR by responding. >> I am not aware of IPR related to this draft. >> >> Thanks, >> >> --John >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 7 15:42:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE7F1A0428 for ; Wed, 7 May 2014 15:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8iFqWdeapnX for ; Wed, 7 May 2014 15:42:09 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E5B721A0427 for ; Wed, 7 May 2014 15:42:08 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-1d-536a67b46b02 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 92.05.07420.4B76A635; Wed, 7 May 2014 19:04:52 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Wed, 7 May 2014 18:42:03 -0400 From: Jeff Tantsura To: Susan Hares , "'John G. Scudder'" , "'idr@ietf. org'" Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: Ac9qIcSDkmbbyvO6RoGDqFwdKrtKLgACqumA Date: Wed, 7 May 2014 22:42:02 +0000 Message-ID: References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> In-Reply-To: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-ID: <08897D791FF81C408B2EFD4BAF797BA3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLrHW3dLelawQfcqY4tXt58xWcy88ZXV 4s+bVywOzB5Llvxk8rjedJXdY/br66wBzFFcNimpOZllqUX6dglcGWuvdDAWbJWv6Nj9n6mB sV2yi5GTQ0LAROL0lzOMELaYxIV769m6GLk4hASOMkr8bprCDuEsY5T4c2kvG0gVm4CBxP9v x1lAbBGBHImW5hNMILawgJvEgQcH2CHi7hKNrf+ZIGwjicfTf4DZLAIqEpfO3wHbxitgLvGv 7T3YHCEBM4n5rXvA5nMCxX/NWAVWwwh00fdTa8B6mQXEJW49mc8EcamAxJI955khbFGJl4// sYLYogJ6Eu+Ow9QoSuzrn84O0asjsWD3J6D5HEC2tcS+jV4QYW2JZQtfM0OcIyhxcuYTlgmM 4rOQbJuFpHsWQvcsJN2zkHQvYGRdxchRWpxalptuZLCJERhnxyTYdHcw7nlpeYhRgINRiYdX gSUrWIg1say4MvcQozQHi5I4b8GX2GAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjHZH7ypU Rpm98D62d97x+DubrK+LWM196+paab1cI8sj8EiKp8zhzRO2vQ49++DOHlEnUb1Dqzm+fJbc JvG8yTBBzjA4oKJL/vy25WXrozfppHa+WiM2x7t+6rqZnTsWJBqfdewMZTh82PLRqjN8d7K3 zQ34c+LwVA+f9yYLzBkUtnNxaov/cVBiKc5INNRiLipOBAA+zSh1lAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/idr/P2qw2PEfMuN6SPCbmtngoezf2DE Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 22:42:11 -0000 Yes/support Cheers, Jeff -----Original Message----- From: Susan Hares Date: Wednesday, May 7, 2014 at 11:31 AM To: "'John G. Scudder'" , "'idr@ietf. org'" Subject: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt >John:=20 > >Congratulations on publishing draft of >draft-ietf-idr-error-handling-07.txt. >This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. >In >your comments please indicate, support/no support for the WG LC. > >Please also indicate if you know if IPR by responding. > >Sue=20 > >-----Original Message----- >From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder >Sent: Wednesday, May 07, 2014 2:17 PM >To: idr@ietf. org >Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt > >Folks, > >Compared to -06, this version lists a couple more NLRI (in)correctness >criteria in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 on >the >handling of typed NLRI (such as for MVPN and EVPN), makes an editorial >clarification regarding when a session must be reset, and removes Appendix >A. The deletion of Appendix A was because it was there for purposes of >explanation in the early versions of the draft, but at this point everyone >seems to get the point and there doesn't seem to be any need to clutter up >the eventual RFC with it. > >With this revision the authors think the document is ready for working >group >last call. > >Thanks, > >--John > >On May 7, 2014, at 2:08 PM, internet-drafts@ietf.org wrote: > >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> This draft is a work item of the Inter-Domain Routing Working Group of >>the >IETF. >>=20 >> Title : Revised Error Handling for BGP UPDATE Messages >> Authors : Enke Chen >> Juniper Networks >> Pradosh Mohapatra >> Keyur Patel >> Filename : draft-ietf-idr-error-handling-07.txt >> Pages : 13 >> Date : 2014-05-07 >>=20 >> Abstract: >> According to the base BGP specification, a BGP speaker that receives >> an UPDATE message containing a malformed attribute is required to >> reset the session over which the offending attribute was received. >> This behavior is undesirable as a session reset would impact not only >> routes with the offending attribute, but also other valid routes >> exchanged over the session. This document partially revises the >> error handling for UPDATE messages, and provides guidelines for the >> authors of documents defining new attributes. Finally, it revises >> the error handling procedures for a number of existing attributes. >>=20 >> This document updates error handling for RFCs 1997, 4271, 4360, 4456, >> 4760, and 5701. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 7 15:43:53 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE091A0422 for ; Wed, 7 May 2014 15:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp4JTTVKMP7p for ; Wed, 7 May 2014 15:43:35 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECA81A0416 for ; Wed, 7 May 2014 15:43:35 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-48-536a680b1a17 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EB.05.07420.B086A635; Wed, 7 May 2014 19:06:19 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Wed, 7 May 2014 18:43:30 -0400 From: Jeff Tantsura To: Jeffrey Haas , "idr@ietf.org" Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: Ac9qIcSDkmbbyvO6RoGDqFwdKrtKLgAIoDKA///QuwA= Date: Wed, 7 May 2014 22:43:29 +0000 Message-ID: References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20140507183247.GE17758@pfrc> In-Reply-To: <20140507183247.GE17758@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-ID: <21A69466F5216C409ADE893EA67E7864@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPrC53RlawwZ0HNhavbj9jsth/8C2r A5PHkiU/mTwu925lDWCK4rJJSc3JLEst0rdL4MqY9+Yie8FSjooJ21czNjC+ZOti5OSQEDCR aNw8hR3CFpO4cG89UJyLQ0jgKKPEqS/vGSGcZYwSG3Z1MYFUsQkYSPz/dpwFxBYRcJA49PYp mC0s4CZx4MEBdoi4u0Rj638mCNtK4vLGdtYuRg4OFgEViZvzwcK8AuYSP1bvBrOFBMIk7k7p BWvlFNCSePhoAiOIzQh00PdTa8BqmAXEJW49geiVEBCQWLLnPDOELSrx8vE/VhBbVEBP4t1x mBpFiX3909khenUkFuz+xAZhW0us+dLPCmFrSyxb+JoZ4h5BiZMzn7BMYBSfhWTdLCTts5C0 z0LSPgtJ+wJG1lWMHKXFqWW56UYGmxiBUXVMgk13B+Oel5aHGAU4GJV4eBVYsoKFWBPLiitz DzFKc7AoifMWfIkNFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAYKMMV/v9JpsNfoaXfdH4t PrBq25rXnU/43rJq+bu4WL/eFjJbOOGM/hzW5zrnvsd/8n2j+0Torf2tpPqCrL8PbsW8kn0+ /01Wsc8yE/bJS3csvq0uMfV0xoS7y+c/2FN366zu+nqXjTN5Nkd1K0rPl95iVRi+2nmDb48l d7PphylTa5Y01RodUGIpzkg01GIuKk4EABjt6X2LAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NUD0Ws8ueEMzu6KmwlafTUIuvfM Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 22:43:36 -0000 Hi Jeff, We are (E///) going thru the last rounds of testing, so count as implemented. Cheers, Jeff -----Original Message----- From: Jeffrey Haas Date: Wednesday, May 7, 2014 at 11:32 AM To: "idr@ietf.org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt >Sue, > >On Wed, May 07, 2014 at 02:31:15PM -0400, Susan Hares wrote: >> Congratulations on publishing draft of >>draft-ietf-idr-error-handling-07.txt. >> This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. >> In >> your comments please indicate, support/no support for the WG LC. >>=20 >> Please also indicate if you know if IPR by responding. > >While an implementation report would be more appropriate, might I also >suggest asking in the poll whether you have an implementation covering the >functionality? > >-- Jeff (who will be responding a qualified yes) > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 8 12:50:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40431A00EA for ; Thu, 8 May 2014 12:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGJHaW2wWbrj for ; Thu, 8 May 2014 12:50:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 05DD41A00D5 for ; Thu, 8 May 2014 12:50:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 79D07C2A8; Thu, 8 May 2014 15:50:29 -0400 (EDT) Date: Thu, 8 May 2014 15:50:29 -0400 From: Jeffrey Haas To: idr@ietf.org, "John G. Scudder" Message-ID: <20140508195029.GB3935@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/cStS7D_H9BVEHDd42E5gxBLevcU Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 19:50:36 -0000 On Mon, Apr 21, 2014 at 04:01:19PM -0400, John G. Scudder wrote: > We have received a request for a working group last call on draft-ietf-idr-flowspec-redirect-rt-bis-00. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-00 > > Please send comments to the list by May 6. Were I the chairs, I'd say the document doesn't have group consensus. Come on folk, give this a fast read. It's short, promise. :-) -- Jeff From nobody Thu May 8 13:32:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2859E1A0144 for ; Thu, 8 May 2014 13:32:05 -0700 (PDT) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASVdanF4cT5i for ; Thu, 8 May 2014 13:32:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9F41E1A0135 for ; Thu, 8 May 2014 13:32:03 -0700 (PDT) Received: from cbardenheuer-sslvpn-nc.jnpr.net (66.129.241.13) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 8 May 2014 20:31:57 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <20140508195029.GB3935@pfrc> Date: Thu, 8 May 2014 16:31:44 -0400 Content-Transfer-Encoding: 7bit Message-ID: <09737BA4-8974-4B97-B01F-7B798F9FB789@juniper.net> References: <20140508195029.GB3935@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BLUPR08CA021.namprd08.prod.outlook.com (10.141.240.41) To BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) X-Forefront-PRVS: 0205EDCD76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(189002)(199002)(24454002)(164054003)(74662001)(76482001)(33656001)(57306001)(74502001)(4396001)(31966008)(46102001)(42186004)(21056001)(62966002)(50226001)(101416001)(89996001)(53416003)(82746002)(97756001)(77982001)(86362001)(93916002)(81342001)(50466002)(23726002)(83072002)(85852003)(92726001)(81542001)(87286001)(92566001)(2009001)(83716003)(77156001)(46406003)(36756003)(88136002)(87976001)(81156002)(69596002)(19580395003)(20776003)(47776003)(64706001)(19580405001)(83322001)(80022001)(99396002)(50986999)(79102001)(76176999)(66066001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB725; H:cbardenheuer-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/tIyG8flkUZC2d2aibDLkLrvVmUo Cc: idr@ietf.org Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 20:32:05 -0000 On May 8, 2014, at 3:50 PM, Jeffrey Haas wrote: > Were I the chairs, I'd say the document doesn't have group consensus. Indeed. :-( > Come on folk, give this a fast read. It's short, promise. :-) Speaking for myself, I did, and I support its publication. I hope others will similarly put in a few minutes to review. Thanks, --John From nobody Thu May 8 13:37:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676031A0135 for ; Thu, 8 May 2014 13:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdnsSMmJcljx for ; Thu, 8 May 2014 13:37:15 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB4E1A00FA for ; Thu, 8 May 2014 13:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=691; q=dns/txt; s=iport; t=1399581431; x=1400791031; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=IJZkk/eGePSOlDx6MYcXzhVa4vM2jUxDrT0N5MrJG+8=; b=N/mEpyW1Ew+l1yBQHUNSyHq60niiOXAP8I/Sr7B6DBdLRhgMHAZaa3zw JcQTIz4qJxKkyYmQvadiDMIjAoeaUUw7hNjOtCayYVVoeKlw81YaTXGxo erXn9qZnfb8QjqJOlgCl/nSBH/JtBVZKTuMU1XT19DXe4g3IA4T11BmZ9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAIfqa1OtJA2I/2dsb2JhbABZgmUhT1i+Joc8AYEUFnSCJQEBAQQBAQE3NB0BCA4KHjcLJQIEARKIQQEM0EwXjlmEPwSZOIE8kT+DNoIv X-IronPort-AV: E=Sophos;i="4.97,1013,1389744000"; d="scan'208";a="42224003" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP; 08 May 2014 20:36:51 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s48KaptH006279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 20:36:51 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Thu, 8 May 2014 15:36:51 -0500 From: "Hyojeong Kim (hyojekim)" To: Jeffrey Haas , "idr@ietf.org" , "John G. Scudder" Thread-Topic: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 Thread-Index: AQHPXZyHuwjwtH9CBUWTXhWaBtr1Qps3hh+A//+XmYA= Date: Thu, 8 May 2014 20:36:50 +0000 Message-ID: In-Reply-To: <20140508195029.GB3935@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.154.212.215] Content-Type: text/plain; charset="us-ascii" Content-ID: <03C03869F2CB58488BFA3FB9D6FCCA8A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hUcWHHmL4Cl1u8ua2l8ZWvMe6GA Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 20:37:17 -0000 I support. On 5/8/14 12:50 PM, "Jeffrey Haas" wrote: >On Mon, Apr 21, 2014 at 04:01:19PM -0400, John G. Scudder wrote: >> We have received a request for a working group last call on >>draft-ietf-idr-flowspec-redirect-rt-bis-00. A URL for the draft is >>http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-00 >>=20 >> Please send comments to the list by May 6. > >Were I the chairs, I'd say the document doesn't have group consensus. > >Come on folk, give this a fast read. It's short, promise. :-) > >-- Jeff > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 8 13:58:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D591A011E for ; Thu, 8 May 2014 13:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncrCcLTR7MTg for ; Thu, 8 May 2014 13:58:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) by ietfa.amsl.com (Postfix) with ESMTP id EAE811A00E7 for ; Thu, 8 May 2014 13:58:23 -0700 (PDT) Received: from cbardenheuer-sslvpn-nc.jnpr.net (66.129.241.13) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 8 May 2014 20:58:15 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <68EFACB32CF4464298EA2779B058889D12488647@PDDCWMBXEX503.ctl.intranet> Date: Thu, 8 May 2014 16:58:02 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3FE697AE-C1F2-448B-8D99-FE5D914A9923@juniper.net> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com>, <9F2CC5C2-FE5A-4585-8DD3-B412B2180150@juniper.net> <68EFACB32CF4464298EA2779B058889D12488647@PDDCWMBXEX503.ctl.intranet> To: "Smith, Donald" X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BLUPR07CA019.namprd07.prod.outlook.com (10.255.223.172) To BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) X-Forefront-PRVS: 0205EDCD76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51704005)(189002)(199002)(24454002)(74662001)(76482001)(33656001)(57306001)(74502001)(4396001)(31966008)(46102001)(42186004)(21056001)(62966002)(50226001)(101416001)(89996001)(53416003)(97756001)(82746002)(77982001)(86362001)(93916002)(50466002)(23726002)(85852003)(83072002)(92726001)(81542001)(87286001)(92566001)(2009001)(83716003)(77156001)(46406003)(36756003)(88136002)(87976001)(81156002)(81342001)(69596002)(19580395003)(20776003)(47776003)(64706001)(19580405001)(83322001)(80022001)(99396002)(50986999)(79102001)(76176999)(66066001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB725; H:cbardenheuer-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/GdsRCqJN9oN03wpHgELbDUZtqoA Cc: "idr@ietf. org" , Hares Susan Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 20:58:26 -0000 Donald, On May 7, 2014, at 4:43 PM, Smith, Donald = wrote: > The error handling of the following case described in Section 6.3 of > [RFC4271] is revised >=20 > If any recognized attribute has Attribute Flags that conflict = with > the Attribute Type Code, then the Error Subcode MUST be set to > Attribute Flags Error. The Data field MUST contain the erroneous > attribute (type, length, and value). >=20 > as follows: >=20 > If any recognized attribute has Attribute Flags that conflict = with > the Attribute Type Code, then the attribute MUST be treated as > malformed and the treat-as-withdraw approach (see below) used, > unless the specification for the attribute mandates different > handling for incorrect Attribute Flags. >=20 >=20 >=20 > Are there specifications for attributes that mandates different = behavior or is that a future looking statement? I'm aware of one, draft-ietf-idr-aigp-18, S. 3.2: If a BGP Path Attribute is received that has the AIGP attribute codepoint, but also has the transitive bit set, the attribute MUST be considered to be a malformed AIGP attribute, and MUST be discarded as specified in this section. Regards, --John= From nobody Thu May 8 15:38:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99151A014E for ; Thu, 8 May 2014 15:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1EE5oLBi9uq for ; Thu, 8 May 2014 15:38:23 -0700 (PDT) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9039F1A014B for ; Thu, 8 May 2014 15:38:23 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so3205917wes.15 for ; Thu, 08 May 2014 15:38:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rCI1lYLid+UW/nfaaEOC+tEBjFeFYakgQ3pbr9ohAlY=; b=Em4pdJUT/+2Njoj3FLBXXLbwOzMrf65fwdaX2QECFGAdWprcvmm/sAFBFiRsRdFALD G4OI+KGs3pNf69UxFmOz2lwtW2gt0EXTtu7V1YtWetSPhqjG4epeqAIaSvlQtqBGtrso brM7HQqqcB9AAVG8sH/JSTEV9VgWPLnmlyw1PxD3V9dpjCPhgwFBILolgRle2c5vh6FQ JOR7WOL+A8pFvE+Jk2dH3VZcuqm6oByvhEf7blrN3gQJTa9d27uO+IgMjjUCKoXGWB5m vY876hS5Bkc4jcM3/AE+epVlt6cowo7sO/k/7d1AnaYkB8amTZx8vP+GAuyIgFg8I/f2 iylA== X-Gm-Message-State: ALoCoQmc1J+aN2YH76iLbsFpPF0sOWFCBmbdtq8bVGXgd+y+yF8tiJsmo3dxdBkky/8GRCLHeXL3 MIME-Version: 1.0 X-Received: by 10.180.189.69 with SMTP id gg5mr327875wic.52.1399588698280; Thu, 08 May 2014 15:38:18 -0700 (PDT) Received: by 10.194.62.70 with HTTP; Thu, 8 May 2014 15:38:18 -0700 (PDT) In-Reply-To: References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> Date: Thu, 8 May 2014 18:38:18 -0400 Message-ID: From: Warren Kumari To: Jeff Tantsura Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ePXrEN-HZZvGn7wRJ-DfQ6FbiM4 Cc: Susan Hares , "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 22:38:25 -0000 On Wed, May 7, 2014 at 6:42 PM, Jeff Tantsura wrote: > Yes/support As do I. W > > Cheers, > Jeff > > > > > -----Original Message----- > From: Susan Hares > Date: Wednesday, May 7, 2014 at 11:31 AM > To: "'John G. Scudder'" , "'idr@ietf. org'" > Subject: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt > >>John: >> >>Congratulations on publishing draft of >>draft-ietf-idr-error-handling-07.txt. >>This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. >>In >>your comments please indicate, support/no support for the WG LC. >> >>Please also indicate if you know if IPR by responding. >> >>Sue >> >>-----Original Message----- >>From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder >>Sent: Wednesday, May 07, 2014 2:17 PM >>To: idr@ietf. org >>Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt >> >>Folks, >> >>Compared to -06, this version lists a couple more NLRI (in)correctness >>criteria in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 on >>the >>handling of typed NLRI (such as for MVPN and EVPN), makes an editorial >>clarification regarding when a session must be reset, and removes Appendix >>A. The deletion of Appendix A was because it was there for purposes of >>explanation in the early versions of the draft, but at this point everyone >>seems to get the point and there doesn't seem to be any need to clutter up >>the eventual RFC with it. >> >>With this revision the authors think the document is ready for working >>group >>last call. >> >>Thanks, >> >>--John >> >>On May 7, 2014, at 2:08 PM, 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 Inter-Domain Routing Working Group of >>>the >>IETF. >>> >>> Title : Revised Error Handling for BGP UPDATE Messages >>> Authors : Enke Chen >>> Juniper Networks >>> Pradosh Mohapatra >>> Keyur Patel >>> Filename : draft-ietf-idr-error-handling-07.txt >>> Pages : 13 >>> Date : 2014-05-07 >>> >>> Abstract: >>> According to the base BGP specification, a BGP speaker that receives >>> an UPDATE message containing a malformed attribute is required to >>> reset the session over which the offending attribute was received. >>> This behavior is undesirable as a session reset would impact not only >>> routes with the offending attribute, but also other valid routes >>> exchanged over the session. This document partially revises the >>> error handling for UPDATE messages, and provides guidelines for the >>> authors of documents defining new attributes. Finally, it revises >>> the error handling procedures for a number of existing attributes. >>> >>> This document updates error handling for RFCs 1997, 4271, 4360, 4456, >>> 4760, and 5701. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-07 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >> >>_______________________________________________ >>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 > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 8 16:55:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8D81A01BE for ; Thu, 8 May 2014 16:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzDd6Y1yYpE5 for ; Thu, 8 May 2014 16:55:33 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id A86021A0173 for ; Thu, 8 May 2014 16:55:33 -0700 (PDT) Received: from [192.168.1.4] (pool-72-73-23-184.clppva.fios.verizon.net [72.73.23.184]) (authenticated bits=0) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s48NtQj6005719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 May 2014 19:55:27 -0400 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <81DF2882-79AE-4DE8-8539-892B1B08460F@puck.nether.net> X-Mailer: iPhone Mail (11D201) From: Jon Mitchell Date: Thu, 8 May 2014 19:55:26 -0400 To: "Hyojeong Kim (hyojekim)" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Thu, 08 May 2014 19:55:27 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/fp4y2_Yn8jvBZzgUBL-RpL6JAuE Cc: "idr@ietf.org" Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 23:55:37 -0000 Support, also the RFC7153 changes I'm seeing on IANA site, guess they got it= fixed? -Jon http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-commun= ities.xhtml > On May 8, 2014, at 4:36 PM, "Hyojeong Kim (hyojekim)" = wrote: >=20 > I support. >=20 >>> On 5/8/14 12:50 PM, "Jeffrey Haas" wrote: >>>=20 >>> On Mon, Apr 21, 2014 at 04:01:19PM -0400, John G. Scudder wrote: >>> We have received a request for a working group last call on >>> draft-ietf-idr-flowspec-redirect-rt-bis-00. A URL for the draft is >>> http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-rt-bis-00 >>>=20 >>> Please send comments to the list by May 6. >>=20 >> Were I the chairs, I'd say the document doesn't have group consensus. >>=20 >> Come on folk, give this a fast read. It's short, promise. :-) >>=20 >> -- Jeff >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 8 16:59:07 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5AE1A0194 for ; Thu, 8 May 2014 16:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rAogAEp18e4 for ; Thu, 8 May 2014 16:58:56 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 31D711A0185 for ; Thu, 8 May 2014 16:58:56 -0700 (PDT) Received: from [192.168.1.4] (pool-72-73-23-184.clppva.fios.verizon.net [72.73.23.184]) (authenticated bits=0) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s48NwnoZ005940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 May 2014 19:58:51 -0400 References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> Mime-Version: 1.0 (1.0) In-Reply-To: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: Jon Mitchell Date: Thu, 8 May 2014 19:58:49 -0400 To: Susan Hares X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Thu, 08 May 2014 19:58:51 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/yky60iBQGjIYOluk2aeQE2ddsqk Cc: "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 23:59:00 -0000 Support. -Jon > On May 7, 2014, at 2:31 PM, "Susan Hares" wrote: >=20 > John:=20 >=20 > Congratulations on publishing draft of draft-ietf-idr-error-handling-07.tx= t. > This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. I= n > your comments please indicate, support/no support for the WG LC.=20 >=20 > Please also indicate if you know if IPR by responding.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Wednesday, May 07, 2014 2:17 PM > To: idr@ietf. org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt >=20 > Folks, >=20 > Compared to -06, this version lists a couple more NLRI (in)correctness > criteria in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 on t= he > handling of typed NLRI (such as for MVPN and EVPN), makes an editorial > clarification regarding when a session must be reset, and removes Appendix= > A. The deletion of Appendix A was because it was there for purposes of > explanation in the early versions of the draft, but at this point everyone= > seems to get the point and there doesn't seem to be any need to clutter up= > the eventual RFC with it.=20 >=20 > With this revision the authors think the document is ready for working gro= up > last call. >=20 > Thanks, >=20 > --John >=20 >> On May 7, 2014, at 2:08 PM, 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 Inter-Domain Routing Working Group of th= e > IETF. >>=20 >> Title : Revised Error Handling for BGP UPDATE Messages >> Authors : Enke Chen >> Juniper Networks >> Pradosh Mohapatra >> Keyur Patel >> Filename : draft-ietf-idr-error-handling-07.txt >> Pages : 13 >> Date : 2014-05-07 >>=20 >> Abstract: >> According to the base BGP specification, a BGP speaker that receives >> an UPDATE message containing a malformed attribute is required to >> reset the session over which the offending attribute was received. >> This behavior is undesirable as a session reset would impact not only >> routes with the offending attribute, but also other valid routes >> exchanged over the session. This document partially revises the >> error handling for UPDATE messages, and provides guidelines for the >> authors of documents defining new attributes. Finally, it revises >> the error handling procedures for a number of existing attributes. >>=20 >> This document updates error handling for RFCs 1997, 4271, 4360, 4456, >> 4760, and 5701. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at > tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 8 22:09:12 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB441A01DB for ; Thu, 8 May 2014 22:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mcmtrih_-s2c for ; Thu, 8 May 2014 22:09:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id B5C8C1A01DA for ; Thu, 8 May 2014 22:09:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wid3L-00068i-KS; Fri, 09 May 2014 05:09:03 +0000 Date: Fri, 09 May 2014 07:09:05 +0200 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20140508195029.GB3935@pfrc> References: <20140508195029.GB3935@pfrc> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rxBAIEel74wGhgIRxIpWv7v86UE Cc: idr wg Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 05:09:10 -0000 sigh. well, ok. if you insist :) i have read the document. it seems needed. it seems to fill the need. so i support it. nit: s/does not matched/does not match/ randy From nobody Fri May 9 00:36:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E20F1A01FE; Fri, 9 May 2014 00:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZlzhf1XRopt; Fri, 9 May 2014 00:35:59 -0700 (PDT) Received: from out-5.mail.exa.net.uk (out-5.mail.exa.net.uk [82.219.4.133]) by ietfa.amsl.com (Postfix) with ESMTP id C12401A01FD; Fri, 9 May 2014 00:35:59 -0700 (PDT) Received: from smtp-2.mail.exa.net.uk (smtp-2.mail.exa.net.uk [82.219.5.2]) by out-5.mail.exa.net.uk (ExaSMTPD) with ESMTP id A9AC71C0091; Fri, 9 May 2014 08:35:53 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 7086A4026C; Fri, 9 May 2014 08:35:53 +0100 (BST) Content-Type: multipart/signed; boundary="Apple-Mail=_A99C130B-C52B-45CB-8EF5-92779350F4A6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Mangin In-Reply-To: <20140508195029.GB3935@pfrc> Date: Fri, 9 May 2014 08:35:52 +0100 X-Mao-Original-Outgoing-Id: 421313751.486156-03352a788708ac2fce81ed1064e1aa40 Message-Id: References: <20140508195029.GB3935@pfrc> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.98.1 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/idr/LJ-jpt-PYkdF7XDsBQOMHnGlGRM Cc: idr@ietf.org Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 07:36:02 -0000 --Apple-Mail=_A99C130B-C52B-45CB-8EF5-92779350F4A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Were I the chairs, I'd say the document doesn't have group consensus. >=20 > Come on folk, give this a fast read. It's short, promise. :-) Or people have busy lives and just planned to reply to this call, = "tomorrow, I promise". 3 days late but support. Thomas --Apple-Mail=_A99C130B-C52B-45CB-8EF5-92779350F4A6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlNshVcACgkQA/52wvuLgaH2QwCfSYpqGk4aeOl+LwUicCEojRZB mggAoJFzLhp+I0yS7hmxErMKaLB+9z/0 =yBjM -----END PGP SIGNATURE----- --Apple-Mail=_A99C130B-C52B-45CB-8EF5-92779350F4A6-- From nobody Fri May 9 05:45:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0F51A02A0; Fri, 9 May 2014 05:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9Qer2POQaSG; Fri, 9 May 2014 05:45:43 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0481A1A0298; Fri, 9 May 2014 05:45:42 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id s49CjWUY015582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 May 2014 07:45:33 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 8723D1E0072; Fri, 9 May 2014 06:45:27 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 6D9A11E006F; Fri, 9 May 2014 06:45:27 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s49CjRtx004262; Fri, 9 May 2014 06:45:27 -0600 (MDT) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s49CjQ03004249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 06:45:27 -0600 (MDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0158.001; Fri, 9 May 2014 06:45:26 -0600 From: "Smith, Donald" To: Thomas Mangin , "idr-bounces@ietf.org" Thread-Topic: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 Thread-Index: AQHPavbPbKU/ch9mQECdm3IeSH2yX5s4QUMA///xnEk= Date: Fri, 9 May 2014 12:45:25 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D1248AEB6@PDDCWMBXEX503.ctl.intranet> References: <20140508195029.GB3935@pfrc>, 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.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/k13QzvfE3C7PCDGFCA34jA__lQ0 Cc: "idr@ietf.org" Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 12:45:44 -0000 +1 it appears to be the desired behavior. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: Idr [idr-bounces@ietf.org] on behalf of Thomas Mangin [thomas.mangin@= exa-networks.co.uk] Sent: Friday, May 09, 2014 1:35 AM To: idr-bounces@ietf.org Cc: idr@ietf.org Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 > Were I the chairs, I'd say the document doesn't have group consensus. >=20 > Come on folk, give this a fast read. It's short, promise. :-) Or people have busy lives and just planned to reply to this call, "tomorro= w, I promise". 3 days late but support. Thomas= From nobody Fri May 9 06:13:07 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD8A1A02AE for ; Fri, 9 May 2014 06:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bviwvZV9J0dU for ; Fri, 9 May 2014 06:12:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF571A029E for ; Fri, 9 May 2014 06:12:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C568DC09E; Fri, 9 May 2014 09:12:41 -0400 (EDT) Date: Fri, 9 May 2014 09:12:41 -0400 From: Jeffrey Haas To: Randy Bush Message-ID: <20140509131241.GA13387@pfrc> References: <20140508195029.GB3935@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/i3Lms8RAkBWiteSqaDH05DQ-TMA Cc: idr wg Subject: Re: [Idr] WGLC for draft-ietf-idr-flowspec-redirect-rt-bis-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 13:13:03 -0000 On Fri, May 09, 2014 at 07:09:05AM +0200, Randy Bush wrote: > sigh. well, ok. if you insist :) > > i have read the document. it seems needed. it seems to fill the need. > so i support it. > > nit: > > s/does not matched/does not match/ Thanks for the review. I've corrected the typo and will include it in a -01. -- Jeff From nobody Fri May 9 07:18:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E121F1A02AE for ; Fri, 9 May 2014 07:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXis5F5b-Eof for ; Fri, 9 May 2014 07:18:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1441A00BE for ; Fri, 9 May 2014 07:18:38 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 083A32AC28C; Fri, 9 May 2014 16:18:33 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id E05B638404A; Fri, 9 May 2014 16:18:32 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 9 May 2014 16:18:32 +0200 From: To: Susan Hares , "'John G. Scudder'" Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: Ac9qIcSDkmbbyvO6RoGDqFwdKrtKLgBPM15Q Date: Fri, 9 May 2014 14:18:32 +0000 Message-ID: <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> In-Reply-To: <008b01cf6a22$87ee08b0$97ca1a10$@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.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.9.93619 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/BvqGyS6k9iWDqASueLs0j7wr63c Cc: "'idr@ietf. org'" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 14:18:42 -0000 Susan, John, I support. Please find below some comments/questions: ------ =A71 Introduction "In the case of optional transitive attributes, the behavior is especially troublesome and may present a potential security vulnerability. The reason is that such attributes may have been propagated without being checked by intermediate routers that do not recognize the attributes -- in effect the attribute may have been tunneled, and when they do reach a router that recognizes and checks them, the session that is reset may not be associated with the router that is at fault." Another reason, and IMO a significant one, is that when the error is detect= ed, this erroneous transitive attribute has reached multiple routers, up to= a significant number, network wide. Therefore this create many multiple si= multaneous failure in the networks, with a large part of the network been a= ffected. When centralized route reflectors are used (e.g. VPN networks), if= the Route Reflector does not recognize the attribute/error, then a signifi= cant part of the IBGP sessions (hence the network) is affected. A third reason, is that a receiver, when detecting an error, will tend to a= lways believe that he is the one to be right and that the error is on the s= ender side; while this may not be the case. The bug or misinterpretation of= the spec could equally be on the receiver or on the sender. Eventually, no= body will ever know (e.g. draft-hares-idr-update-attrib-low-bits-fix). So i= f the error is in fact on the receiver side, again we have multiple routers= detecting a bug at the same time, just like with unknown transitive attrib= utes. So let's be humble when we detect an error, and let's not consider th= at the speaker is to buggy to talk to and we'd be safer kicking it outside = the network. Bottom line, my main reason is the fear of the multiplier effect (one wrong= message triggers multiple BGP sessions failures) ----- =A72 Revision to the base spec. Editorial: IMHO, page 4 lacks structure which makes it harder to identify t= he different cases of error. I would propose to add a number (or sub paragr= aph). e.g.=20 OLD : The error handling of the following case described in Section 6.= 3 of [RFC4271] is revised NEW: 2) The error handling of the following case described in Section 6.3 o= f [RFC4271] is revised ---- Editorial: "This document partially revises [...] provides guidelines for t= he authors of documents defining new attributes." I would propose to group these guidelines in a specific paragraph. Indeed, = such guidelines are expected to be referred to and read for each new IDR sp= ec. (while currently, those guidelines are a bit spread in the document) ---- =A7 3.3. Typed NLRI " A BGP speaker advertising support for such a typed address family MUST handle routes with unrecognized NLRI types within that address family by discarding them, unless the relevant specification for that address family specifies otherwise." The latest part seems strange: " unless the relevant specification for that= address family specifies otherwise". Indeed, given that the NLRI types are= unrecognized by the BGP speaker, it seems strange to mandate him to comply= with the spec which is unknown to him. ------ Editorial/nit picking: =A75.11/5.12 & 5.5 have chosen a different way of ex= pressing the same thing. =A75.5 groups per (type of error (malformed or ill= egitimate presence) , type of session) while =A75.11/5.12 groups per (type = of session, type or error). Personally I have a preference for the =A75.11/= 5.12 way, which is more concise. ------ What's next after WGLC ? Over the last years, the draft has been regularly updated, showing that thi= s subject is a large and difficult. Unless we have a reason to believe that= now the spec is final and perfect, what is the plan for the next spec chan= ge (in 12 months ;-) )? Are we ready/ok to create a bis draft? ------ Thanks, Regards, Bruno > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Wednesday, May 07, 2014 8:31 PM > To: 'John G. Scudder'; 'idr@ietf. org' > Subject: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt >=20 > John: >=20 > Congratulations on publishing draft of draft-ietf-idr-error-handling-07.t= xt. > This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. = In > your comments please indicate, support/no support for the WG LC. >=20 > Please also indicate if you know if IPR by responding. >=20 > Sue >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Wednesday, May 07, 2014 2:17 PM > To: idr@ietf. org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt >=20 > Folks, >=20 > Compared to -06, this version lists a couple more NLRI (in)correctness cr= iteria > in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 on the handl= ing of > typed NLRI (such as for MVPN and EVPN), makes an editorial clarification > regarding when a session must be reset, and removes Appendix A. The > deletion of Appendix A was because it was there for purposes of explanati= on > in the early versions of the draft, but at this point everyone seems to g= et the > point and there doesn't seem to be any need to clutter up the eventual RFC > with it. >=20 > With this revision the authors think the document is ready for working gr= oup > last call. >=20 > Thanks, >=20 > --John >=20 > On May 7, 2014, at 2:08 PM, internet-drafts@ietf.org wrote: >=20 > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Inter-Domain Routing Working Group of > > the > IETF. > > > > Title : Revised Error Handling for BGP UPDATE Messages > > Authors : Enke Chen > > Juniper Networks > > Pradosh Mohapatra > > Keyur Patel > > Filename : draft-ietf-idr-error-handling-07.txt > > Pages : 13 > > Date : 2014-05-07 > > > > Abstract: > > According to the base BGP specification, a BGP speaker that receives > > an UPDATE message containing a malformed attribute is required to > > reset the session over which the offending attribute was received. > > This behavior is undesirable as a session reset would impact not only > > routes with the offending attribute, but also other valid routes > > exchanged over the session. This document partially revises the > > error handling for UPDATE messages, and provides guidelines for the > > authors of documents defining new attributes. Finally, it revises > > the error handling procedures for a number of existing attributes. > > > > This document updates error handling for RFCs 1997, 4271, 4360, 4456, > > 4760, and 5701. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-07 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri May 9 07:18:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4E81A02B2 for ; Fri, 9 May 2014 07:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7_E3oHF121c for ; Fri, 9 May 2014 07:18:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id BDF731A02AE for ; Fri, 9 May 2014 07:18:42 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 10A0B3B417B; Fri, 9 May 2014 16:18:37 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E883E27C058; Fri, 9 May 2014 16:18:36 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 9 May 2014 16:18:36 +0200 From: To: "John G. Scudder" , "Smith, Donald" Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: Ac9qIcSDkmbbyvO6RoGDqFwdKrtKLv//93oAgAANmoCAAZZCAP/+xuXA Date: Fri, 9 May 2014 14:18:36 +0000 Message-ID: <23690_1399645117_536CE3BC_23690_6179_1_53C29892C857584299CBF5D05346208A0714710C@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com>, <9F2CC5C2-FE5A-4585-8DD3-B412B2180150@juniper.net> <68EFACB32CF4464298EA2779B058889D12488647@PDDCWMBXEX503.ctl.intranet> <3FE697AE-C1F2-448B-8D99-FE5D914A9923@juniper.net> In-Reply-To: <3FE697AE-C1F2-448B-8D99-FE5D914A9923@juniper.net> 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: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.9.93619 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/qlSSlqgnNjyC5MtsnRXK2k7AIj0 Cc: "idr@ietf. org" , Hares Susan Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 14:18:45 -0000 Donald, John, > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Donald, >=20 > On May 7, 2014, at 4:43 PM, Smith, Donald > wrote: >=20 > > The error handling of the following case described in Section 6.3 of > > [RFC4271] is revised > > > > If any recognized attribute has Attribute Flags that conflict with > > the Attribute Type Code, then the Error Subcode MUST be set to > > Attribute Flags Error. The Data field MUST contain the erroneous > > attribute (type, length, and value). > > > > as follows: > > > > If any recognized attribute has Attribute Flags that conflict with > > the Attribute Type Code, then the attribute MUST be treated as > > malformed and the treat-as-withdraw approach (see below) used, > > unless the specification for the attribute mandates different > > handling for incorrect Attribute Flags. > > > > > > > > Are there specifications for attributes that mandates different behavio= r or > is that a future looking statement? >=20 > I'm aware of one, draft-ietf-idr-aigp-18, S. 3.2: My understanding of draft-ietf-idr-error-handling-07 is that it seems to de= fine a different behavior (session shutdown) for 2 other attributes: MP_REA= CH, MP_UNREACH - =A73.2: "the MP_REACH or MP_UNREACH attribute of an update SHALL be consi= dered to be incorrect if [...] The attribute flags of the attribute are inconsistent with those specified = in [RFC4760]." -=A72: " in order to use the approach of "treat-as- withdraw", the entire NLRI field and/or the MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to be successfully parsed. If this is not possible, the procedures of [RFC4271] continue to apply, meaning that the session MUST be reset and a NOTIFICATION sent. Alternatively the error handling procedures specified in [RFC4760] for disabling a particular AFI/SAFI MAY be followed. One notable case where it would be not possible to successfully parse the NLRI is if the NLRI field is found to be "syntactically incorrect" (see Section 3.2)." Is this a correct understanding? Is this intended (that a flag error in att= ributes MP_(UN)REACH triggers a session shutdown) ? Thanks, Regards, Bruno >=20 > If a BGP Path Attribute is received that has the AIGP attribute > codepoint, but also has the transitive bit set, the attribute MUST be > considered to be a malformed AIGP attribute, and MUST be discarded as > specified in this section. >=20 > Regards, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri May 9 08:09:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBED1A0045 for ; Fri, 9 May 2014 08:09:33 -0700 (PDT) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2vprZCamVVD for ; Fri, 9 May 2014 08:09:28 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD991A0009 for ; Fri, 9 May 2014 08:08:42 -0700 (PDT) Received: from cbardenheuer-sslvpn-nc.jnpr.net (66.129.241.13) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.934.12; Fri, 9 May 2014 15:08:36 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Fri, 9 May 2014 11:08:26 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <87358378-754C-44AD-817E-4FE28C0A9E14@juniper.net> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BLUPR02CA004.namprd02.prod.outlook.com (10.255.223.152) To BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) X-Forefront-PRVS: 02065A9E77 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(189002)(199002)(377454003)(51704005)(83716003)(92566001)(87286001)(2009001)(77156001)(88136002)(81542001)(92726001)(83072002)(85852003)(36756003)(23756003)(79102001)(19580395003)(83322001)(19580405001)(80022001)(76176999)(66066001)(20776003)(87976001)(50986999)(64706001)(81342001)(69596002)(47776003)(81156002)(50466002)(46102001)(31966008)(82746002)(42186004)(74662001)(76482001)(74502001)(33656001)(4396001)(86362001)(21056001)(77982001)(93916002)(100916002)(89996001)(62966002)(53416003)(101416001)(50226001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB725; H:cbardenheuer-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/QMjq5VuLloY90mKUvWIRQ42GvF8 Cc: "idr@ietf. org" , Hares Susan Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:09:34 -0000 Hi Bruno, Thanks for your comments. Some responses below. I haven't commented on = your editorial/nit points but will see if I can find a way to = incorporate them and may follow up later. On May 9, 2014, at 10:18 AM, = wrote: > =A71 Introduction > "In the case of optional > transitive attributes, the behavior is especially troublesome and = may ... > Bottom line, my main reason is the fear of the multiplier effect (one = wrong message triggers multiple BGP sessions failures) I agree with your points, especially regarding the multiplier effect. = Are you suggesting we introduce this reasoning into the draft? At this = point I think it's not critical to provide extensive rationale -- we = have moved on from convincing ourselves of the importance of the = problem, to agreeing on the specification of how to fix it. This is what = motivated the removal of Appendix A. > =A7 3.3. Typed NLRI >=20 > " A BGP speaker advertising support for such a typed address family > MUST handle routes with unrecognized NLRI types within that address > family by discarding them, unless the relevant specification for = that > address family specifies otherwise." >=20 > The latest part seems strange: " unless the relevant specification for = that address family specifies otherwise". Indeed, given that the NLRI = types are unrecognized by the BGP speaker, it seems strange to mandate = him to comply with the spec which is unknown to him. Possibly this should be written differently to be clearer. Let me = provide an example. Suppose a route reflector advertises MP-BGP support = for AFI/SAFI 25/70 (L2VPN/EVPN). EVPN NLRI are structured as TLVs: +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+ However there is no place in the MP-BGP capability for the route = reflector to say "I support EVPN route types 1, 2, 3 and 4". Suppose = EVPN route type 5 is specified at some point. When the route reflector = receives a type-5 EVPN route, what is it supposed to do? The options = would seem to be - Hard error, reset session - Soft error, discard the route (default action in the draft) - Something else (the EVPN spec should say what) An earlier unpublished revision of the text called the section = "TLV-structured NLRI" but one of the reviewers pointed out that it = applies even to NLRI that might not be formally a TLV, e.g. a structure = that just uses a type and a value, where length is implied by type. > What's next after WGLC ? > Over the last years, the draft has been regularly updated, showing = that this subject is a large and difficult. Unless we have a reason to = believe that now the spec is final and perfect, what is the plan for the = next spec change (in 12 months ;-) )? Are we ready/ok to create a bis = draft? IMO, yes. Of course we could continue error-handling as a seemingly = eternal draft, but I think there is some value in saying "close enough" = and graduating it to RFC, especially for implementors that are less = steeped in the WG and don't necessarily have the background to = distinguish between Internet Drafts that are really *drafts* and those = that are de-facto standards. --John= From nobody Fri May 9 08:15:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6979F1A0296 for ; Fri, 9 May 2014 08:15:12 -0700 (PDT) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9L-Wi6COO7C for ; Fri, 9 May 2014 08:15:08 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9161A02B3 for ; Fri, 9 May 2014 08:15:08 -0700 (PDT) Received: from cbardenheuer-sslvpn-nc.jnpr.net (66.129.241.13) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.934.12; Fri, 9 May 2014 15:15:01 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <23690_1399645117_536CE3BC_23690_6179_1_53C29892C857584299CBF5D05346208A0714710C@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Fri, 9 May 2014 11:14:54 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7CC15DE0-D2D7-43C5-AF2C-8C102D4641F1@juniper.net> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com>, <9F2CC5C2-FE5A-4585-8DD3-B412B2180150@juniper.net> <68EFACB32CF4464298EA2779B058889D12488647@PDDCWMBXEX503.ctl.intranet> <3FE697AE-C1F2-448B-8D99-FE5D914A9923@juniper.net> <23690_1399645117_536CE3BC_23690_6179_1_53C29892C857584299CBF5D05346208A0714710C@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BLUPR02CA003.namprd02.prod.outlook.com (10.255.223.151) To BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) X-Forefront-PRVS: 02065A9E77 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(189002)(199002)(377454003)(52604005)(83716003)(92566001)(87286001)(2009001)(77156001)(88136002)(81542001)(92726001)(83072002)(85852003)(36756003)(23756003)(79102001)(19580395003)(83322001)(19580405001)(80022001)(76176999)(66066001)(20776003)(87976001)(50986999)(64706001)(81342001)(69596002)(47776003)(81156002)(50466002)(46102001)(31966008)(82746002)(42186004)(74662001)(76482001)(74502001)(33656001)(4396001)(558084003)(86362001)(21056001)(77982001)(93916002)(100916002)(89996001)(62966002)(53416003)(101416001)(50226001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB725; H:cbardenheuer-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vWdS2b1Mh0ETX6l_mGNwUm5bgHY Cc: "idr@ietf. org" , Hares Susan Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:15:12 -0000 On May 9, 2014, at 10:18 AM, = wrote: > Is this a correct understanding? Is this intended (that a flag error = in attributes MP_(UN)REACH triggers a session shutdown) ? Yes, for the reasons you quoted from S. 2. Thanks for pointing it out, --John= From nobody Fri May 9 08:49:35 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AC41A02C4 for ; Fri, 9 May 2014 08:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_8HKQ5gTf7I for ; Fri, 9 May 2014 08:49:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 642A81A02CC for ; Fri, 9 May 2014 08:49:27 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 42C643741FE; Fri, 9 May 2014 17:49:22 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 288A938404A; Fri, 9 May 2014 17:49:22 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 9 May 2014 17:49:22 +0200 From: To: "John G. Scudder" Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: AQHPa5iP1jUmZUB2pk+pHBkI7kVkWJs4YEPg Date: Fri, 9 May 2014 15:49:21 +0000 Message-ID: <20299_1399650562_536CF902_20299_11373_1_53C29892C857584299CBF5D05346208A07147242@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup> <87358378-754C-44AD-817E-4FE28C0A9E14@juniper.net> In-Reply-To: <87358378-754C-44AD-817E-4FE28C0A9E14@juniper.net> 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: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.9.93619 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/I1PE9tzFBKft1LbugbVPBYbtIqo Cc: "idr@ietf. org" , Hares Susan Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 15:49:30 -0000 Hi John, Thanks for your answers. Please see inline. > From: John G. Scudder [mailto:jgs@juniper.net] >=20 > Hi Bruno, >=20 > Thanks for your comments. Some responses below. I haven't commented on > your editorial/nit points but will see if I can find a way to incorporate= them > and may follow up later. >=20 > On May 9, 2014, at 10:18 AM, > wrote: > > =A71 Introduction > > "In the case of optional > > transitive attributes, the behavior is especially troublesome and may > ... > > Bottom line, my main reason is the fear of the multiplier effect (one w= rong > message triggers multiple BGP sessions failures) >=20 > I agree with your points, especially regarding the multiplier effect. Are= you > suggesting we introduce this reasoning into the draft?=20 I was indeed suggesting introducing the "multiplier effect" motivation. I agree with you that this is not critical in the doc, so it's really up to= you. I thought I could be useful for network operator, especially for impl= ementations which do not enable new error handling by default. Hence the op= erator needs to understand the importance of the feature. >At this point I think it's > not critical to provide extensive rationale -- we have moved on from > convincing ourselves of the importance of the problem, to agreeing on the > specification of how to fix it. This is what motivated the removal of App= endix > A. >=20 > > =A7 3.3. Typed NLRI >=20 > > > > " A BGP speaker advertising support for such a typed address family > > MUST handle routes with unrecognized NLRI types within that address > > family by discarding them, unless the relevant specification for that > > address family specifies otherwise." > > > > The latest part seems strange: " unless the relevant specification for = that > address family specifies otherwise". Indeed, given that the NLRI types are > unrecognized by the BGP speaker, it seems strange to mandate him to > comply with the spec which is unknown to him. >=20 > Possibly this should be written differently to be clearer. Let me provide= an > example.=20 Thanks for the example. The current text was clear. It's just me who was not familiar with typed NL= RI and who read the text too quickly. My mistake. >Suppose a route reflector advertises MP-BGP support for AFI/SAFI > 25/70 (L2VPN/EVPN). EVPN NLRI are structured as TLVs: >=20 > +-----------------------------------+ > | Route Type (1 octet) | > +-----------------------------------+ > | Length (1 octet) | > +-----------------------------------+ > | Route Type specific (variable) | > +-----------------------------------+ >=20 > However there is no place in the MP-BGP capability for the route reflecto= r to > say "I support EVPN route types 1, 2, 3 and 4". Suppose EVPN route type 5= is > specified at some point. When the route reflector receives a type-5 EVPN > route, what is it supposed to do? The options would seem to be >=20 > - Hard error, reset session > - Soft error, discard the route (default action in the draft) > - Something else (the EVPN spec should say what) >=20 > An earlier unpublished revision of the text called the section "TLV-struc= tured > NLRI" but one of the reviewers pointed out that it applies even to NLRI t= hat > might not be formally a TLV, e.g. a structure that just uses a type and a= value, > where length is implied by type. >=20 > > What's next after WGLC ? > > Over the last years, the draft has been regularly updated, showing that= this > subject is a large and difficult. Unless we have a reason to believe that= now > the spec is final and perfect, what is the plan for the next spec change = (in 12 > months ;-) )? Are we ready/ok to create a bis draft? >=20 > IMO, yes. Of course we could continue error-handling as a seemingly etern= al > draft, but I think there is some value in saying "close enough" and gradu= ating > it to RFC, especially for implementors that are less steeped in the WG and > don't necessarily have the background to distinguish between Internet > Drafts that are really *drafts* and those that are de-facto standards. Thanks for the clarification. I support moving forward the current draft to= RFC. I was just checking whether the authors were ok with continuing the w= ork if needed Regards, Bruno >=20 > --John ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Sun May 11 02:25:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE511A01F0 for ; Sun, 11 May 2014 02:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFT59phRkXUy for ; Sun, 11 May 2014 02:25:10 -0700 (PDT) Received: from mail.crfreenet.org (mail6.crfreenet.org [IPv6:2002:515c:9101:20::10]) by ietfa.amsl.com (Postfix) with ESMTP id 0B87B1A01DD for ; Sun, 11 May 2014 02:25:09 -0700 (PDT) Received: from localhost (feanor.crfreenet.org [81.92.145.132]) by mail.crfreenet.org (Postfix) with ESMTP id D02C0FCD1; Sun, 11 May 2014 11:25:00 +0200 (CEST) Received: from santiago by localhost with local (Exim 4.69) (envelope-from ) id 1WjQbF-0008Ib-1K; Sun, 11 May 2014 12:03:17 +0200 Date: Sun, 11 May 2014 12:03:16 +0200 From: Ondrej Zajicek To: Susan Hares , "John G. Scudder" Message-ID: <20140511100316.GA12659@localhost> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> X-Operating-System: Debian GNU/Linux User-Agent: Mutt/1.5.18 (2008-05-17) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/mJ0X03u5-BKloIuzxW-Sf1eXCr0 Cc: idr@ietf.org Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 09:25:13 -0000 On Wed, May 07, 2014 at 02:31:15PM -0400, Susan Hares wrote: > John: > > Congratulations on publishing draft of draft-ietf-idr-error-handling-07.txt. Hello Here are my comments to the draft. Maybe some of these issues are not relevant or were already discussed and settled, in that case i am sorry for the noise. 5.2. AS_PATH The draft says 'The error conditions for the attribute have been defined in [RFC4271]'. Unfortunately, RFC 4271 is rather vague about error conditions for AS_PATH. It says just: "The AS_PATH attribute is checked for syntactic correctness. If the path is syntactically incorrect, then the Error Subcode MUST be set to Malformed AS_PATH." Without exactly specifying the syntactic correctness of AS_PATH. Although most if it is intuitive and self-explanatory, there are several issues (AFAIK) not addressed anywhere: 1) Is incorrect AS_PATH with unknown (undefined in RFC 4271) segment types (i.e. different ones than AS_SET or AS_SEQUENCE)? I would guess yes unless receiver knows these new types (like AS_CONFED_* from RFC 5065), but 'no' can be also viewed as reasonable possibility. 2) Is incorrect AS_PATH that cannot be generated by rules from RFC 4271 5.1.2? E.g. path containing two small sequence segments? I would guess no, but yes is also reasonable possibility (if your view on syntax and grammar is more generative than descriptive). 3) Is incorrect AS_PATH that contains seqments of zero length? I would say yes according to strict reading of RFC 4271 4.3, although syntactically there is no problem with them. Also note that the draft implicitly updates RFC 5065 part 5 (BGP confederations, error handling), as these error conditions (for AS_CONFED_* fields in unexpected contexts) should be handled by treat-as-withdraw instead of session-reset. 5.3. NEXT_HOP Also a bit vague. RFC 4271 6.3 defines syntactical and semantical correctness for NEXT_HOP attribute. A syntactically incorrect attribute is obviously malformed, but it is not clear whether the attribute should be considered maformed if it is just semantically incorrect. Part 2 of the draft suggests it shouldn't (as it does not specify a session reset in RFC 4271). I would suggest to replace 'The error conditions for the NEXT_HOP attribute ...' with 'The attribute is considered malformed if it is syntactically incorrect according to RFC 4271', if that is what was meant. 5.8. Community 5.9. Extended community 5.10. IPv6 Address Specific BGP Extended Community Attribute I am a bit confused by the formulation 'malformed if its length is nonzero and is not a multiple of 4/8/20'. I would understand that the first part is redundant (as zero length is also a multiple of 4/8/20 and is therefore OK), but in 5.12 Cluster list, the nonzeroness is not explicitly mentioned in the similar case. Is this variation significant? I would suppose it is not and both communities and cluster lists of zero length are valid. In that case, perhaps it would be a good idea to use the same wording for both communities and cluster lists. 5.11. ORIGINATOR_ID 5.12. CLUSTER_LIST Note that error handling of RFC 4456 also specifies the behavior for 'semantically incorrect' CLUSTER_LIST containing local ORIGINATOR_ID (the condition caused by routing loop). This case is not mentioned in the discussed draft (perhaps intentionally as it is semantic and not syntactic error). Also note that RFC 4456 specifies that such update should be ignored, although that behavior is obviously broken and perhaps should be replaced with treat-as-withdraw. The same also holds for received ORIGINATOR_ID attribute containing local value. -- Ondrej 'Santiago' Zajicek From nobody Mon May 12 07:39:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7191A0715 for ; Mon, 12 May 2014 07:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM0N7VgLWxeo for ; Mon, 12 May 2014 07:39:51 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id CCE051A0711 for ; Mon, 12 May 2014 07:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=968; q=dns/txt; s=iport; t=1399905584; x=1401115184; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9Ke0uLSoVSU/2dFh504iEU/3aPSKYjcu9lkZw1TKUAk=; b=NE/DG5Yo/06gEOjtLs42QBK4WbofkYeCjKoDUV6cFBUqK3fClvZ4NP4p P/UO3QLoV7Y6Qj1UH6S1i4zQ7x/GmxUxsrPTufxpYgUoor2cMt+U9SuDF 04CxjETUuHRH1rdlHSLbFI837Z6k3mFy2wPEtlWnrPiTyjvw/tirqaUP2 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAJHccFOtJV2a/2dsb2JhbABZgwZPWL4yhzsBgRgWdIIlAQEBBAEBATc0CxIBCBgeNwslAgQBDQWIQQ3PERMEjlIHhEABA5lIkweDNoIv X-IronPort-AV: E=Sophos;i="4.97,1035,1389744000"; d="scan'208";a="43083585" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 12 May 2014 14:39:43 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4CEdhYa031780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 14:39:43 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 12 May 2014 09:39:43 -0500 From: "Gaurav Dawra (gdawra)" To: "Keyur Patel (keyupate)" , "Enke Chen (enkechen)" , "John G. Scudder" , Hares Susan Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: AQHPbfAD4MTOyPxbjEm226vGGA3bNA== Date: Mon, 12 May 2014 14:39:43 +0000 Message-ID: In-Reply-To: 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.151.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/VidJC5-Tum-lgk5XxGZShUbfTI4 Cc: "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 14:39:53 -0000 +1 Regards, -Gaurav On 5/7/14 2:29 PM, "Keyur Patel (keyupate)" wrote: >+1. > >Regards, >Keyur > >On 5/7/14 1:22 PM, "Enke Chen" wrote: > >>I am not aware of any IPRs related to this draft either. >> >>Thanks. -- Enke >> >>On 5/7/14 12:55 PM, John G. Scudder wrote: >>> On May 7, 2014, at 2:31 PM, Susan Hares wrote: >>> >>>> Please also indicate if you know if IPR by responding. >>> I am not aware of IPR related to this draft. >>> >>> Thanks, >>> >>> --John >>> >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www.ietf.org/mailman/listinfo/idr > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Mon May 12 09:35:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395D91A0757 for ; Mon, 12 May 2014 09:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDWUZzaX9pEF for ; Mon, 12 May 2014 09:34:57 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id F1C7D1A0711 for ; Mon, 12 May 2014 09:34:56 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-97-5370a8e46a0d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 78.24.07420.4E8A0735; Mon, 12 May 2014 12:56:36 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Mon, 12 May 2014 12:34:49 -0400 From: Jakob Heitz To: Susan Hares , "'John G. Scudder'" , "'idr@ietf. org'" Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: Ac9qIcSDkmbbyvO6RoGDqFwdKrtKLgD3jR/w Date: Mon, 12 May 2014 16:34:49 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03054686@eusaamb109.ericsson.se> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> In-Reply-To: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXRPuO6TFQXBBivW61q8uv2MyWLmja+s Fn/evGJxYPZYsuQnk8f1pqvsHrNfX2cNYI7isklJzcksSy3St0vgyjjad5+t4Ixcxertm9ga GBdJdDFyckgImEhMbPzDBmGLSVy4tx7I5uIQEjjKKLHyyW1mCGc5o8TRCccZQarYBHQkvl3v YgaxRQRyJFqaTzB1MXJwCAu4SSy7WAARdpdobP0PFhYRMJLYdK8QJMwioCqx5N59sE5eAV+J 9S9vg+0VEjCTmN+6B8zmFDCX+DVjFdgmRqB7vp9awwRiMwuIS9x6Mp8J4k4BiSV7zjND2KIS Lx//Y4WwlSQmLT3HClGvI7Fg9yc2CFtbYtnC11B7BSVOznzCMoFRdBaSsbOQtMxC0jILScsC RpZVjBylxalluelGBpsYgfFxTIJNdwfjnpeWhxgFOBiVeHgXzC4IFmJNLCuuzD3EKM3BoiTO W/AlNlhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo6aLzbuHe/b8ey4qfG6Xwc1jD46wL9vd y/5ZeVFxW2BMe+KVyTsu/LqWnBDFuGiJq1G95oQfGbfPhy2vCzuqOOl9sF1PXGfdTon6YBPP D2+jFZe9EfJS0yrJO7r40LFTgaUlcYXt2UViYrNWrk54Eb6pyLL3o/tMk2sR02PzUnYeVbmo GXs9WomlOCPRUIu5qDgRAGercJ5wAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/idr/DWoKvkeMoAkx1g2rTZar0EpS6sU Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 16:34:59 -0000 I support. -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Wednesday, May 07, 2014 11:31 AM To: 'John G. Scudder'; 'idr@ietf. org' Subject: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt John:=20 Congratulations on publishing draft of draft-ietf-idr-error-handling-07.txt= . This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. In= your comments please indicate, support/no support for the WG LC.=20 Please also indicate if you know if IPR by responding.=20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Wednesday, May 07, 2014 2:17 PM To: idr@ietf. org Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt Folks, Compared to -06, this version lists a couple more NLRI (in)correctness crit= eria in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 on the ha= ndling of typed NLRI (such as for MVPN and EVPN), makes an editorial clarif= ication regarding when a session must be reset, and removes Appendix A. The= deletion of Appendix A was because it was there for purposes of explanatio= n in the early versions of the draft, but at this point everyone seems to g= et the point and there doesn't seem to be any need to clutter up the eventu= al RFC with it.=20 With this revision the authors think the document is ready for working grou= p last call. Thanks, --John On May 7, 2014, at 2:08 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing Working Group of=20 > the IETF. >=20 > Title : Revised Error Handling for BGP UPDATE Messages > Authors : Enke Chen > Juniper Networks > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-07.txt > Pages : 13 > Date : 2014-05-07 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. >=20 > This document updates error handling for RFCs 1997, 4271, 4360, 4456, > 4760, and 5701. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon May 12 12:21:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81041A0781 for ; Mon, 12 May 2014 12:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVIkLH2BkHRB for ; Mon, 12 May 2014 12:20:56 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E3F091A0785 for ; Mon, 12 May 2014 12:20:46 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id as1so7543223iec.3 for ; Mon, 12 May 2014 12:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8wPdT7FI9cyUJbRWXGpbJRRTn397sWoGfAT+W5HT/io=; b=kQQKpAXDFG6HQJKZ73fJTreaQ6mjDIJ1Wr4YN9dv9oVeZeYGfYU7KHCVpe0/5+OitZ 5HXq+iPJlPoM1yNh9tLYJ0AsYcwieJnRhJlcT17a/1ornr9qo/orDJw865UEwIneRsAA 3Du5iQzUx/vuJo6qN0aYyDCECrJ01oW+ZqurFCqJMUJ7Ys39isXytQzA/DUI9UOB+/zS +munj6qCOqLiOO+JvunmV/0HqRpVy2y+VynVelcbkWPAQpUXePKs605SPcksM8dhWO6Q 71XhV5IhraMEPpW7TftSrctipXBykQjN2+JE9cuVNiAGeZPvDeYqq/rALj6X9KBfHs7y 39CA== MIME-Version: 1.0 X-Received: by 10.50.109.230 with SMTP id hv6mr47433436igb.9.1399922440888; Mon, 12 May 2014 12:20:40 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 12 May 2014 12:20:40 -0700 (PDT) In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E03054686@eusaamb109.ericsson.se> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E03054686@eusaamb109.ericsson.se> Date: Mon, 12 May 2014 21:20:40 +0200 X-Google-Sender-Auth: 0VbBGeSVLq_3W-74EB89v_4Ba0Y Message-ID: From: Robert Raszuk To: Jakob Heitz Content-Type: multipart/alternative; boundary=089e013a1d8ecd6a5f04f938d73e Archived-At: http://mailarchive.ietf.org/arch/msg/idr/3ovPNMKPmVtaqMsR1-xcQ3vUUyc Cc: Susan Hares , "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 19:20:59 -0000 --089e013a1d8ecd6a5f04f938d73e Content-Type: text/plain; charset=UTF-8 Support. r. On Mon, May 12, 2014 at 6:34 PM, Jakob Heitz wrote: > I support. > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > Sent: Wednesday, May 07, 2014 11:31 AM > To: 'John G. Scudder'; 'idr@ietf. org' > Subject: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt > > John: > > Congratulations on publishing draft of > draft-ietf-idr-error-handling-07.txt. > This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. > In your comments please indicate, support/no support for the WG LC. > > Please also indicate if you know if IPR by responding. > > Sue > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Wednesday, May 07, 2014 2:17 PM > To: idr@ietf. org > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt > > Folks, > > Compared to -06, this version lists a couple more NLRI (in)correctness > criteria in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 on > the handling of typed NLRI (such as for MVPN and EVPN), makes an editorial > clarification regarding when a session must be reset, and removes Appendix > A. The deletion of Appendix A was because it was there for purposes of > explanation in the early versions of the draft, but at this point everyone > seems to get the point and there doesn't seem to be any need to clutter up > the eventual RFC with it. > > With this revision the authors think the document is ready for working > group last call. > > Thanks, > > --John > > On May 7, 2014, at 2:08 PM, 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 Inter-Domain Routing Working Group of > > the > IETF. > > > > Title : Revised Error Handling for BGP UPDATE Messages > > Authors : Enke Chen > > Juniper Networks > > Pradosh Mohapatra > > Keyur Patel > > Filename : draft-ietf-idr-error-handling-07.txt > > Pages : 13 > > Date : 2014-05-07 > > > > Abstract: > > According to the base BGP specification, a BGP speaker that receives > > an UPDATE message containing a malformed attribute is required to > > reset the session over which the offending attribute was received. > > This behavior is undesirable as a session reset would impact not only > > routes with the offending attribute, but also other valid routes > > exchanged over the session. This document partially revises the > > error handling for UPDATE messages, and provides guidelines for the > > authors of documents defining new attributes. Finally, it revises > > the error handling procedures for a number of existing attributes. > > > > This document updates error handling for RFCs 1997, 4271, 4360, 4456, > > 4760, and 5701. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-07 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > 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 > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --089e013a1d8ecd6a5f04f938d73e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support.

r.


On Mon, May 12, 2014 at 6:34 PM, Jakob Heitz <jakob.heitz@ericsson= .com> wrote:
I support.

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.= org] On Behalf Of Susan Hares
Sent: Wednesday, May 07, 2014 11:31 AM
To: 'John G. Scudder'; 'idr@ietf. org'
Subject: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt

John:

Congratulations on publishing draft of draft-ietf-idr-error-handling-07.txt= .
This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. =C2= =A0In your comments please indicate, support/no support for the WG LC.

Please also indicate if you know if IPR by responding.

Sue

-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.= org] On Behalf Of John G. Scudder
Sent: Wednesday, May 07, 2014 2:17 PM
To: idr@ietf. org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt

Folks,

Compared to -06, this version lists a couple more NLRI (in)correctness crit= eria in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 on the ha= ndling of typed NLRI (such as for MVPN and EVPN), makes an editorial clarif= ication regarding when a session must be reset, and removes Appendix A. The= deletion of Appendix A was because it was there for purposes of explanatio= n in the early versions of the draft, but at this point everyone seems to g= et the point and there doesn't seem to be any need to clutter up the ev= entual RFC with it.

With this revision the authors think the document is ready for working grou= p last call.

Thanks,

--John

On May 7, 2014, at 2:08 PM, int= ernet-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 Inter-Domain Routing Working Group of=
> the
IETF.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = Revised Error Handling for BGP UPDATE Messages
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Enke = Chen
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Juniper Networks
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Pradosh Mohapatra
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Keyur Patel
> =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-= idr-error-handling-07.txt
> =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 13
> =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2= 014-05-07
>
> Abstract:
> =C2=A0 According to the base BGP specification, a BGP speaker that rec= eives
> =C2=A0 an UPDATE message containing a malformed attribute is required = to
> =C2=A0 reset the session over which the offending attribute was receiv= ed.
> =C2=A0 This behavior is undesirable as a session reset would impact no= t only
> =C2=A0 routes with the offending attribute, but also other valid route= s
> =C2=A0 exchanged over the session. =C2=A0This document partially revis= es the
> =C2=A0 error handling for UPDATE messages, and provides guidelines for= the
> =C2=A0 authors of documents defining new attributes. =C2=A0Finally, it= revises
> =C2=A0 the error handling procedures for a number of existing attribut= es.
>
> =C2=A0 This document updates error handling for RFCs 1997, 4271, 4360,= 4456,
> =C2=A0 4760, and 5701.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-err= or-handling/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-idr-error-handlin= g-07
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i= dr-error-handling-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
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

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

--089e013a1d8ecd6a5f04f938d73e-- From nobody Mon May 12 13:22:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6361A0773; Mon, 12 May 2014 13:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYfAVecKk-jk; Mon, 12 May 2014 13:22:20 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) by ietfa.amsl.com (Postfix) with ESMTP id 19D0E1A076B; Mon, 12 May 2014 13:22:20 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt Thread-Index: AQHPah9uwh36SgIDzkmilMvym9LpWZs9aFcA Date: Mon, 12 May 2014 20:22:08 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011EC090@EX01.swan.local> References: <20140507180846.28346.38054.idtracker@ietfa.amsl.com> In-Reply-To: <20140507180846.28346.38054.idtracker@ietfa.amsl.com> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.44.10] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/n9sQVRDkRrgEVjYgSBzLaA8k51E Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 20:22:22 -0000 Hello Authors, I believe that in sections: 5.11. ORIGINATOR_ID And 5.12. CLUSTER_LIST Concerning error handling=20 If these attributes are received from an external neighbor, it SHALL actual= ly be handled using the approach of "treat-as-withdraw. The current "attribute discard" approach can lead to severe Inter-AS loops = e.g. in RFC4364 Opt. 10.C implementations.=20 adam > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Wednesday, May 07, 2014 8:09 PM > To: i-d-announce@ietf.org > Cc: idr@ietf.org > Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Inter-Domain Routing Working Group of t= he > IETF. >=20 > Title : Revised Error Handling for BGP UPDATE Messages > Authors : Enke Chen > Juniper Networks > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-07.txt > Pages : 13 > Date : 2014-05-07 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. >=20 > This document updates error handling for RFCs 1997, 4271, 4360, 4456, > 4760, and 5701. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon May 12 19:33:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400051A03BA; Mon, 12 May 2014 19:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzejfdWEroIi; Mon, 12 May 2014 19:33:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) by ietfa.amsl.com (Postfix) with ESMTP id D99BA1A0816; Mon, 12 May 2014 19:33:14 -0700 (PDT) Received: from jcottingham-sslvpn-nc.jnpr.net (66.129.241.12) by BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) with Microsoft SMTP Server (TLS) id 15.0.934.12; Tue, 13 May 2014 02:33:06 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011EC090@EX01.swan.local> Date: Mon, 12 May 2014 19:32:53 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <4E44A310-BE4D-4016-852F-351C100C7728@juniper.net> References: <20140507180846.28346.38054.idtracker@ietfa.amsl.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EC090@EX01.swan.local> To: =?iso-8859-1?Q?Vitkovsk=FD_Adam?= X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR01CA012.prod.exchangelabs.com (10.141.30.42) To BY2PR05MB725.namprd05.prod.outlook.com (10.141.223.13) X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377424004)(377454003)(51704005)(13464003)(199002)(164054003)(24454002)(189002)(31966008)(21056001)(82746002)(76482001)(74662001)(4396001)(74502001)(33656001)(62966002)(50226001)(77982001)(53416003)(83072002)(15202345003)(23756003)(100916002)(93916002)(86362001)(42186004)(101416001)(89996001)(36756003)(92726001)(83716003)(92566001)(81542001)(87286001)(2009001)(77156001)(69596002)(88136002)(46102001)(83322001)(50986999)(66066001)(57306001)(79102001)(85852003)(15975445006)(47776003)(64706001)(76176999)(20776003)(99396002)(87976001)(19580405001)(19580395003)(80022001)(102836001)(81156002)(50466002)(81342001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB725; H:jcottingham-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NktwvuGejBtlfI2AmWuZMtTDnN8 Cc: "idr@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 02:33:17 -0000 Can you elaborate how these Inter-AS loops would form, maybe with an = example? To my understanding, Option C uses EBGP and thus the regular = AS_PATH would suppress loops. Thanks, --John On May 12, 2014, at 1:22 PM, Vitkovsk=FD Adam = wrote: > Hello Authors, >=20 > I believe that in sections: >=20 > 5.11. ORIGINATOR_ID > And > 5.12. CLUSTER_LIST >=20 > Concerning error handling=20 > If these attributes are received from an external neighbor, it SHALL = actually be handled using the approach of "treat-as-withdraw. >=20 > The current "attribute discard" approach can lead to severe Inter-AS = loops e.g. in RFC4364 Opt. 10.C implementations.=20 >=20 >=20 >=20 > adam >=20 >> -----Original Message----- >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Wednesday, May 07, 2014 8:09 PM >> To: i-d-announce@ietf.org >> Cc: idr@ietf.org >> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Inter-Domain Routing Working Group = of the >> IETF. >>=20 >> Title : Revised Error Handling for BGP UPDATE = Messages >> Authors : Enke Chen >> Juniper Networks >> Pradosh Mohapatra >> Keyur Patel >> Filename : draft-ietf-idr-error-handling-07.txt >> Pages : 13 >> Date : 2014-05-07 >>=20 >> Abstract: >> According to the base BGP specification, a BGP speaker that = receives >> an UPDATE message containing a malformed attribute is required to >> reset the session over which the offending attribute was received. >> This behavior is undesirable as a session reset would impact not = only >> routes with the offending attribute, but also other valid routes >> exchanged over the session. This document partially revises the >> error handling for UPDATE messages, and provides guidelines for the >> authors of documents defining new attributes. Finally, it revises >> the error handling procedures for a number of existing attributes. >>=20 >> This document updates error handling for RFCs 1997, 4271, 4360, = 4456, >> 4760, and 5701. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue May 13 01:11:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AE71A0857 for ; Tue, 13 May 2014 01:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvjAWv_1y0Cl for ; Tue, 13 May 2014 01:11:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 20BB61A0859 for ; Tue, 13 May 2014 01:11:18 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 3BB661B83B5; Tue, 13 May 2014 10:11:11 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 10780158052; Tue, 13 May 2014 10:11:11 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 13 May 2014 10:11:10 +0200 From: To: "'John G. Scudder'" Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: Ac9qIcSD1jUmZUB2pk+pHBkI7kVkWABPM15QAMeV68A= Date: Tue, 13 May 2014 08:11:10 +0000 Message-ID: <6937_1399968671_5371D39F_6937_5572_1_53C29892C857584299CBF5D05346208A07148FB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@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.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.13.43021 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/u1Rso78BpesMKAXjueNMzTZuIDU Cc: "'idr@ietf. org'" , Susan Hares Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 08:11:21 -0000 John, all, In the current version of the draft, attribute flags that conflict with the= attribute type code are handled with "treat-as-withdraw". This good IMO. However, an exception is done for 2 attributes: MP_(UN)REACH_NLRI. For thos= e 2 attributes, such flag error is handled with "Session reset". I don't re= call much debate on this point so I'd like to initiate a discussion on this= point. On my side, I would rather also handle this with "treat-as-withdraw" for th= e following reasons: - as a simplification to avoid an exception - I'm not convinced that an error in the container of the attribute is a si= gnificant indicator that the value of the attribute has more chance to be w= rong. i.e. why should we treat as erroneous a syntaxely correct attribute v= alue? Especially since the consequence will be a session reset. AFAIK we do= n't have data to support that, for an attribute having a valid value field,= there is more chance to have an undetectable error in the value field of t= he attribute when these 2 flags have an error. - in the specific case of this 2 attributes, these 2 flags seems to have li= mited benefit. Indeed, their purpose is to define what the receiver should = do if it does not understand the attribute. But here, the speaker knows (th= rough BGP capability) that the receiver do understand that attribute. So killing a BGP session for 1 or 2 erroneous bit which serves little purpo= se seems a bit strict to me and I would rather propose to remove that excep= tion. More specifically remove "The attribute flags of the attribute are in= consistent with those specified in [RFC4760]" as an error conditions for MP= _(UN)REACH_NLRI attributes. Thanks, Bruno > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of > bruno.decraene@orange.com > Sent: Friday, May 09, 2014 4:19 PM > To: Susan Hares; 'John G. Scudder' > Cc: 'idr@ietf. org' > Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt >=20 > Susan, John, >=20 > I support. >=20 > Please find below some comments/questions: >=20 > ------ > =A71 Introduction > "In the case of optional > transitive attributes, the behavior is especially troublesome and may > present a potential security vulnerability. The reason is that such > attributes may have been propagated without being checked by > intermediate routers that do not recognize the attributes -- in > effect the attribute may have been tunneled, and when they do reach a > router that recognizes and checks them, the session that is reset may > not be associated with the router that is at fault." >=20 > Another reason, and IMO a significant one, is that when the error is > detected, this erroneous transitive attribute has reached multiple router= s, up > to a significant number, network wide. Therefore this create many multiple > simultaneous failure in the networks, with a large part of the network be= en > affected. When centralized route reflectors are used (e.g. VPN networks),= if > the Route Reflector does not recognize the attribute/error, then a signif= icant > part of the IBGP sessions (hence the network) is affected. >=20 > A third reason, is that a receiver, when detecting an error, will tend to= always > believe that he is the one to be right and that the error is on the sende= r side; > while this may not be the case. The bug or misinterpretation of the spec > could equally be on the receiver or on the sender. Eventually, nobody will > ever know (e.g. draft-hares-idr-update-attrib-low-bits-fix). So if the er= ror is > in fact on the receiver side, again we have multiple routers detecting a = bug at > the same time, just like with unknown transitive attributes. So let's be > humble when we detect an error, and let's not consider that the speaker is > to buggy to talk to and we'd be safer kicking it outside the network. >=20 > Bottom line, my main reason is the fear of the multiplier effect (one wro= ng > message triggers multiple BGP sessions failures) > ----- > =A72 Revision to the base spec. >=20 > Editorial: IMHO, page 4 lacks structure which makes it harder to identify= the > different cases of error. I would propose to add a number (or sub > paragraph). e.g. > OLD : The error handling of the following case described in Section = 6.3 of > [RFC4271] is revised > NEW: 2) The error handling of the following case described in Section 6.3= of > [RFC4271] is revised >=20 > ---- > Editorial: "This document partially revises [...] provides guidelines for= the > authors of documents defining new attributes." >=20 > I would propose to group these guidelines in a specific paragraph. Indeed, > such guidelines are expected to be referred to and read for each new IDR > spec. (while currently, those guidelines are a bit spread in the document) > ---- > =A7 3.3. Typed NLRI >=20 > " A BGP speaker advertising support for such a typed address family > MUST handle routes with unrecognized NLRI types within that address > family by discarding them, unless the relevant specification for that > address family specifies otherwise." >=20 > The latest part seems strange: " unless the relevant specification for th= at > address family specifies otherwise". Indeed, given that the NLRI types are > unrecognized by the BGP speaker, it seems strange to mandate him to > comply with the spec which is unknown to him. > ------ > Editorial/nit picking: =A75.11/5.12 & 5.5 have chosen a different way of > expressing the same thing. =A75.5 groups per (type of error (malformed or > illegitimate presence) , type of session) while =A75.11/5.12 groups per (= type of > session, type or error). Personally I have a preference for the =A75.11/5= .12 > way, which is more concise. >=20 > ------ > What's next after WGLC ? > Over the last years, the draft has been regularly updated, showing that t= his > subject is a large and difficult. Unless we have a reason to believe that= now > the spec is final and perfect, what is the plan for the next spec change = (in 12 > months ;-) )? Are we ready/ok to create a bis draft? > ------ >=20 > Thanks, > Regards, > Bruno >=20 >=20 > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares > > Sent: Wednesday, May 07, 2014 8:31 PM > > To: 'John G. Scudder'; 'idr@ietf. org' > > Subject: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt > > > > John: > > > > Congratulations on publishing draft of draft-ietf-idr-error-handling-07= .txt. > > This begins a 2 week WG LC starting today (5/7/14), and ending > > 5/21/14. In your comments please indicate, support/no support for the > WG LC. > > > > Please also indicate if you know if IPR by responding. > > > > Sue > > > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > > Sent: Wednesday, May 07, 2014 2:17 PM > > To: idr@ietf. org > > Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt > > > > Folks, > > > > Compared to -06, this version lists a couple more NLRI (in)correctness > > criteria in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 > > on the handling of typed NLRI (such as for MVPN and EVPN), makes an > > editorial clarification regarding when a session must be reset, and > > removes Appendix A. The deletion of Appendix A was because it was > > there for purposes of explanation in the early versions of the draft, > > but at this point everyone seems to get the point and there doesn't > > seem to be any need to clutter up the eventual RFC with it. > > > > With this revision the authors think the document is ready for working > > group last call. > > > > Thanks, > > > > --John > > > > On May 7, 2014, at 2:08 PM, 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 Inter-Domain Routing Working Group > > > of the > > IETF. > > > > > > Title : Revised Error Handling for BGP UPDATE Messag= es > > > Authors : Enke Chen > > > Juniper Networks > > > Pradosh Mohapatra > > > Keyur Patel > > > Filename : draft-ietf-idr-error-handling-07.txt > > > Pages : 13 > > > Date : 2014-05-07 > > > > > > Abstract: > > > According to the base BGP specification, a BGP speaker that receives > > > an UPDATE message containing a malformed attribute is required to > > > reset the session over which the offending attribute was received. > > > This behavior is undesirable as a session reset would impact not on= ly > > > routes with the offending attribute, but also other valid routes > > > exchanged over the session. This document partially revises the > > > error handling for UPDATE messages, and provides guidelines for the > > > authors of documents defining new attributes. Finally, it revises > > > the error handling procedures for a number of existing attributes. > > > > > > This document updates error handling for RFCs 1997, 4271, 4360, 445= 6, > > > 4760, and 5701. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-idr-error-handling-07 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-07 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > > 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 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > 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 de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue May 13 04:03:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FD01A005A; Tue, 13 May 2014 04:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMtnNVatWaM7; Tue, 13 May 2014 04:03:25 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAFF1A0051; Tue, 13 May 2014 04:03:15 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: "John G. Scudder" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt Thread-Index: AQHPah9uwh36SgIDzkmilMvym9LpWZs9aFcAgABJK4CAAIcxoA== Date: Tue, 13 May 2014 11:03:03 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011EC2C8@EX01.swan.local> References: <20140507180846.28346.38054.idtracker@ietfa.amsl.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EC090@EX01.swan.local> <4E44A310-BE4D-4016-852F-351C100C7728@juniper.net> In-Reply-To: <4E44A310-BE4D-4016-852F-351C100C7728@juniper.net> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.44.10] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/iIsyDkvte9qemAbohAJHIjdoyRg Cc: "idr@ietf.org" , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 11:03:27 -0000 > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Tuesday, May 13, 2014 4:33 AM >=20 > Can you elaborate how these Inter-AS loops would form, maybe with an > example? To my understanding, Option C uses EBGP and thus the regular > AS_PATH would suppress loops. >=20 > Thanks, >=20 > --John Hello John, Sorry for the bad choice of words I thought that the updates might start lo= oping in remote ASes.=20 However now I see that the ORIGINATOR_ID and CLUSTER_LIST attributes, even = if deleted on ingress from an eBGP session, are going to be recreated by th= e RRs(clusters) in the remote AS when the update is propagated further so n= o loops can occur in the remote ASes.=20 However I'm not sure how the ORIGINATOR_ID should be recreated (local route= r id or the eBGP peer ip address) So actually the worst that can happen is asymmetric routing or sub-optimal = path selection if one relies on originator ID or the cluster list length fo= r best path selection.=20 Example: AS-D receives an update for X via AS-B and AS-C.=20 AS-B is a big AS so the update made it through several clusters when propag= ated across.=20 AS-C is a small AS so the update crossed only one cluster on its way to AS-= D.=20 Now let's assume the CLUSTER_LIST attribute is deleted on ingress to AS-D o= n a malformed update from AS-B.=20 For PEs in AS-D the path via AS-C now appears to be less preferred because = it has a longer CLUSTER_LIST.=20 adam From nobody Tue May 13 08:02:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E911A00D7 for ; Tue, 13 May 2014 08:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52n_QLzMzGU3 for ; Tue, 13 May 2014 08:02:05 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2971A00DC for ; Tue, 13 May 2014 08:02:01 -0700 (PDT) X-AuditID: c618062d-f79c96d000001cfc-93-5371e49060fe Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B9.2C.07420.094E1735; Tue, 13 May 2014 11:23:28 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Tue, 13 May 2014 11:01:54 -0400 From: Jakob Heitz To: "bruno.decraene@orange.com" Thread-Topic: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt Thread-Index: Ac9qIcSDkmbbyvO6RoGDqFwdKrtKLgBPM15QANF2wwAABfZNfw== Date: Tue, 13 May 2014 15:01:53 +0000 Message-ID: <4DD15BC0-290C-4533-A744-130C95F75E72@ericsson.com> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup>, <6937_1399968671_5371D39F_6937_5572_1_53C29892C857584299CBF5D05346208A07148FB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <6937_1399968671_5371D39F_6937_5572_1_53C29892C857584299CBF5D05346208A07148FB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXRPiO6EJ4XBBr8naVv82DGH2eLV7WdM FjNvfGW1+PPmFYsDi8eSJT+ZPK43XWX3mP36OqtHy7OTbAEsUVw2Kak5mWWpRfp2CVwZx4/N YCpY0ctYce7qGuYGxhudjF2MnBwSAiYSV9sfskDYYhIX7q1n62Lk4hASOMoo8a2zlRHCWc4o seLkZrAqNgEdiW/Xu5hBbBEBa4kHE0E6ODmYBbIkfl76zARiCwu4SRx4cIAdosZdorH1PxOE 7SSx59hGMJtFQFViyp+jQHM4OHgF7CVuPg6H2LWOSWJC6zOwKzgF2hglrs18CXYqI9B530+t YYJYJi5x68l8JoizBSSW7DnPDGGLSrx8/I8VokZLYl7Db6h6RYkp3Q/BDuIVEJQ4OfMJywRG 0VlIRs1C0jILScssJC0LGFlWMXKUFqeW5aYbGWxiBEbPMQk23R2Me15aHmIU4GBU4uFdMLsg WIg1say4MvcQozQHi5I4b8GX2GAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjHGML/7MuP5a 9Pv7/dce3Xu7Zi3L3o6pPb/vtE3hUTo/49q7mb4F7XXztmzQu/n2p0XfHV/tecc+KbXH9Gu8 EpBMOsg+QVBhXaT7q+O3MiPf/v68kbH2w+8/KV6zD1a9OzUrPnOWhK+5l7WWTco12zvLA15I yM8IWMlT53h2Wo+3T3/HKSVhmfdKLMUZiYZazEXFiQCzhRy5fwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hq0ERJnSWVjwS4bt_tcwJguCt_c Cc: Susan Hares , "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 15:02:11 -0000 SW4gbXkgdW5kZXJzdGFuZGluZywgdGhlIHJlYXNvbiB0byByZXNldCBhIHNlc3Npb24gaXMgaWYg dGhlIE5MUkkgY2Fubm90IGJlIHBhcnNlZC4gQW4gZXJyb3IgaW4gdGhvc2UgYml0cyBkb2VzIG5v dCBzZWVtIHRvIGhpbmRlciB0aGUgcGFyc2FiaWxpdHkgb2YgdGhlIE5MUkkgYW55IG1vcmUgdGhh biBhbnkgb3RoZXIgZXJyb3IgaW4gdGhlIHVwZGF0ZSBtZXNzYWdlLiBUaGVyZWZvcmUsIEkgYWdy ZWUgd2l0aCBCcnVuby4NCg0KLS0NCkpha29iIEhlaXR6Lg0KDQoNCj4gT24gTWF5IDEzLCAyMDE0 LCBhdCAxOjExIEFNLCAiYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSIgPGJydW5vLmRlY3JhZW5l QG9yYW5nZS5jb20+IHdyb3RlOg0KPiANCj4gSm9obiwgYWxsLA0KPiANCj4gSW4gdGhlIGN1cnJl bnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQsIGF0dHJpYnV0ZSBmbGFncyB0aGF0IGNvbmZsaWN0IHdp dGggdGhlIGF0dHJpYnV0ZSB0eXBlIGNvZGUgYXJlIGhhbmRsZWQgd2l0aCAidHJlYXQtYXMtd2l0 aGRyYXciLiBUaGlzIGdvb2QgSU1PLg0KPiANCj4gSG93ZXZlciwgYW4gZXhjZXB0aW9uIGlzIGRv bmUgZm9yIDIgYXR0cmlidXRlczogTVBfKFVOKVJFQUNIX05MUkkuIEZvciB0aG9zZSAyIGF0dHJp YnV0ZXMsIHN1Y2ggZmxhZyBlcnJvciBpcyBoYW5kbGVkIHdpdGggIlNlc3Npb24gcmVzZXQiLiBJ IGRvbid0IHJlY2FsbCBtdWNoIGRlYmF0ZSBvbiB0aGlzIHBvaW50IHNvIEknZCBsaWtlIHRvIGlu aXRpYXRlIGEgZGlzY3Vzc2lvbiBvbiB0aGlzIHBvaW50Lg0KPiANCj4gT24gbXkgc2lkZSwgSSB3 b3VsZCByYXRoZXIgYWxzbyBoYW5kbGUgdGhpcyB3aXRoICJ0cmVhdC1hcy13aXRoZHJhdyIgZm9y IHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCj4gLSBhcyBhIHNpbXBsaWZpY2F0aW9uIHRvIGF2b2lk IGFuIGV4Y2VwdGlvbg0KPiAtIEknbSBub3QgY29udmluY2VkIHRoYXQgYW4gZXJyb3IgaW4gdGhl IGNvbnRhaW5lciBvZiB0aGUgYXR0cmlidXRlIGlzIGEgc2lnbmlmaWNhbnQgaW5kaWNhdG9yIHRo YXQgdGhlIHZhbHVlIG9mIHRoZSBhdHRyaWJ1dGUgaGFzIG1vcmUgY2hhbmNlIHRvIGJlIHdyb25n LiBpLmUuIHdoeSBzaG91bGQgd2UgdHJlYXQgYXMgZXJyb25lb3VzIGEgc3ludGF4ZWx5IGNvcnJl Y3QgYXR0cmlidXRlIHZhbHVlPyBFc3BlY2lhbGx5IHNpbmNlIHRoZSBjb25zZXF1ZW5jZSB3aWxs IGJlIGEgc2Vzc2lvbiByZXNldC4gQUZBSUsgd2UgZG9uJ3QgaGF2ZSBkYXRhIHRvIHN1cHBvcnQg dGhhdCwgZm9yIGFuIGF0dHJpYnV0ZSBoYXZpbmcgYSB2YWxpZCB2YWx1ZSBmaWVsZCwgdGhlcmUg aXMgbW9yZSBjaGFuY2UgdG8gaGF2ZSBhbiB1bmRldGVjdGFibGUgZXJyb3IgaW4gdGhlIHZhbHVl IGZpZWxkIG9mIHRoZSBhdHRyaWJ1dGUgd2hlbiB0aGVzZSAyIGZsYWdzIGhhdmUgYW4gZXJyb3Iu DQo+IC0gaW4gdGhlIHNwZWNpZmljIGNhc2Ugb2YgdGhpcyAyIGF0dHJpYnV0ZXMsIHRoZXNlIDIg ZmxhZ3Mgc2VlbXMgdG8gaGF2ZSBsaW1pdGVkIGJlbmVmaXQuIEluZGVlZCwgdGhlaXIgcHVycG9z ZSBpcyB0byBkZWZpbmUgd2hhdCB0aGUgcmVjZWl2ZXIgc2hvdWxkIGRvIGlmIGl0IGRvZXMgbm90 IHVuZGVyc3RhbmQgdGhlIGF0dHJpYnV0ZS4gQnV0IGhlcmUsIHRoZSBzcGVha2VyIGtub3dzICh0 aHJvdWdoIEJHUCBjYXBhYmlsaXR5KSB0aGF0IHRoZSByZWNlaXZlciBkbyB1bmRlcnN0YW5kIHRo YXQgYXR0cmlidXRlLg0KPiANCj4gU28ga2lsbGluZyBhIEJHUCBzZXNzaW9uIGZvciAxIG9yIDIg ZXJyb25lb3VzIGJpdCB3aGljaCBzZXJ2ZXMgbGl0dGxlIHB1cnBvc2Ugc2VlbXMgYSBiaXQgc3Ry aWN0IHRvIG1lIGFuZCBJIHdvdWxkIHJhdGhlciBwcm9wb3NlIHRvIHJlbW92ZSB0aGF0IGV4Y2Vw dGlvbi4gTW9yZSBzcGVjaWZpY2FsbHkgcmVtb3ZlICJUaGUgYXR0cmlidXRlIGZsYWdzIG9mIHRo ZSBhdHRyaWJ1dGUgYXJlIGluY29uc2lzdGVudCB3aXRoIHRob3NlIHNwZWNpZmllZCBpbiBbUkZD NDc2MF0iIGFzIGFuIGVycm9yIGNvbmRpdGlvbnMgZm9yIE1QXyhVTilSRUFDSF9OTFJJIGF0dHJp YnV0ZXMuDQo+IA0KPiBUaGFua3MsDQo+IEJydW5vDQo+IA0KPiANCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+PiBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tDQo+PiBTZW50OiBGcmlk YXksIE1heSAwOSwgMjAxNCA0OjE5IFBNDQo+PiBUbzogU3VzYW4gSGFyZXM7ICdKb2huIEcuIFNj dWRkZXInDQo+PiBDYzogJ2lkckBpZXRmLiBvcmcnDQo+PiBTdWJqZWN0OiBSZTogW0lkcl0gMiBX ZWVrIFdHIExDOiBkcmFmdC1pZXRmLWlkci1lcnJvci1oYW5kbGluZy0wNy50eHQNCj4+IA0KPj4g U3VzYW4sIEpvaG4sDQo+PiANCj4+IEkgc3VwcG9ydC4NCj4+IA0KPj4gUGxlYXNlIGZpbmQgYmVs b3cgc29tZSBjb21tZW50cy9xdWVzdGlvbnM6DQo+PiANCj4+IC0tLS0tLQ0KPj4goewxIEludHJv ZHVjdGlvbg0KPj4gIkluIHRoZSBjYXNlIG9mIG9wdGlvbmFsDQo+PiAgIHRyYW5zaXRpdmUgYXR0 cmlidXRlcywgdGhlIGJlaGF2aW9yIGlzIGVzcGVjaWFsbHkgdHJvdWJsZXNvbWUgYW5kIG1heQ0K Pj4gICBwcmVzZW50IGEgcG90ZW50aWFsIHNlY3VyaXR5IHZ1bG5lcmFiaWxpdHkuICBUaGUgcmVh c29uIGlzIHRoYXQgc3VjaA0KPj4gICBhdHRyaWJ1dGVzIG1heSBoYXZlIGJlZW4gcHJvcGFnYXRl ZCB3aXRob3V0IGJlaW5nIGNoZWNrZWQgYnkNCj4+ICAgaW50ZXJtZWRpYXRlIHJvdXRlcnMgdGhh dCBkbyBub3QgcmVjb2duaXplIHRoZSBhdHRyaWJ1dGVzIC0tIGluDQo+PiAgIGVmZmVjdCB0aGUg YXR0cmlidXRlIG1heSBoYXZlIGJlZW4gdHVubmVsZWQsIGFuZCB3aGVuIHRoZXkgZG8gcmVhY2gg YQ0KPj4gICByb3V0ZXIgdGhhdCByZWNvZ25pemVzIGFuZCBjaGVja3MgdGhlbSwgdGhlIHNlc3Np b24gdGhhdCBpcyByZXNldCBtYXkNCj4+ICAgbm90IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgcm91 dGVyIHRoYXQgaXMgYXQgZmF1bHQuIg0KPj4gDQo+PiBBbm90aGVyIHJlYXNvbiwgYW5kIElNTyBh IHNpZ25pZmljYW50IG9uZSwgaXMgdGhhdCB3aGVuIHRoZSBlcnJvciBpcw0KPj4gZGV0ZWN0ZWQs IHRoaXMgZXJyb25lb3VzIHRyYW5zaXRpdmUgYXR0cmlidXRlIGhhcyByZWFjaGVkIG11bHRpcGxl IHJvdXRlcnMsIHVwDQo+PiB0byBhIHNpZ25pZmljYW50IG51bWJlciwgbmV0d29yayB3aWRlLiBU aGVyZWZvcmUgdGhpcyBjcmVhdGUgbWFueSBtdWx0aXBsZQ0KPj4gc2ltdWx0YW5lb3VzIGZhaWx1 cmUgaW4gdGhlIG5ldHdvcmtzLCB3aXRoIGEgbGFyZ2UgcGFydCBvZiB0aGUgbmV0d29yayBiZWVu DQo+PiBhZmZlY3RlZC4gV2hlbiBjZW50cmFsaXplZCByb3V0ZSByZWZsZWN0b3JzIGFyZSB1c2Vk IChlLmcuIFZQTiBuZXR3b3JrcyksIGlmDQo+PiB0aGUgUm91dGUgUmVmbGVjdG9yIGRvZXMgbm90 IHJlY29nbml6ZSB0aGUgYXR0cmlidXRlL2Vycm9yLCB0aGVuIGEgc2lnbmlmaWNhbnQNCj4+IHBh cnQgb2YgdGhlIElCR1Agc2Vzc2lvbnMgKGhlbmNlIHRoZSBuZXR3b3JrKSBpcyBhZmZlY3RlZC4N Cj4+IA0KPj4gQSB0aGlyZCByZWFzb24sIGlzIHRoYXQgYSByZWNlaXZlciwgd2hlbiBkZXRlY3Rp bmcgYW4gZXJyb3IsIHdpbGwgdGVuZCB0byBhbHdheXMNCj4+IGJlbGlldmUgdGhhdCBoZSBpcyB0 aGUgb25lIHRvIGJlIHJpZ2h0IGFuZCB0aGF0IHRoZSBlcnJvciBpcyBvbiB0aGUgc2VuZGVyIHNp ZGU7DQo+PiB3aGlsZSB0aGlzIG1heSBub3QgYmUgdGhlIGNhc2UuIFRoZSBidWcgb3IgbWlzaW50 ZXJwcmV0YXRpb24gb2YgdGhlIHNwZWMNCj4+IGNvdWxkIGVxdWFsbHkgYmUgb24gdGhlIHJlY2Vp dmVyIG9yIG9uIHRoZSBzZW5kZXIuIEV2ZW50dWFsbHksIG5vYm9keSB3aWxsDQo+PiBldmVyIGtu b3cgKGUuZy4gZHJhZnQtaGFyZXMtaWRyLXVwZGF0ZS1hdHRyaWItbG93LWJpdHMtZml4KS4gU28g aWYgdGhlIGVycm9yIGlzDQo+PiBpbiBmYWN0IG9uIHRoZSByZWNlaXZlciBzaWRlLCBhZ2FpbiB3 ZSBoYXZlIG11bHRpcGxlIHJvdXRlcnMgZGV0ZWN0aW5nIGEgYnVnIGF0DQo+PiB0aGUgc2FtZSB0 aW1lLCBqdXN0IGxpa2Ugd2l0aCB1bmtub3duIHRyYW5zaXRpdmUgYXR0cmlidXRlcy4gU28gbGV0 J3MgYmUNCj4+IGh1bWJsZSB3aGVuIHdlIGRldGVjdCBhbiBlcnJvciwgYW5kIGxldCdzIG5vdCBj b25zaWRlciB0aGF0IHRoZSBzcGVha2VyIGlzDQo+PiB0byBidWdneSB0byB0YWxrIHRvIGFuZCB3 ZSdkIGJlIHNhZmVyIGtpY2tpbmcgaXQgb3V0c2lkZSB0aGUgbmV0d29yay4NCj4+IA0KPj4gQm90 dG9tIGxpbmUsIG15IG1haW4gcmVhc29uIGlzIHRoZSBmZWFyIG9mIHRoZSBtdWx0aXBsaWVyIGVm ZmVjdCAob25lIHdyb25nDQo+PiBtZXNzYWdlIHRyaWdnZXJzIG11bHRpcGxlIEJHUCBzZXNzaW9u cyBmYWlsdXJlcykNCj4+IC0tLS0tDQo+PiCh7DIgUmV2aXNpb24gdG8gdGhlIGJhc2Ugc3BlYy4N Cj4+IA0KPj4gRWRpdG9yaWFsOiBJTUhPLCBwYWdlIDQgbGFja3Mgc3RydWN0dXJlIHdoaWNoIG1h a2VzIGl0IGhhcmRlciB0byBpZGVudGlmeSB0aGUNCj4+IGRpZmZlcmVudCBjYXNlcyBvZiBlcnJv ci4gSSB3b3VsZCBwcm9wb3NlIHRvIGFkZCBhIG51bWJlciAob3Igc3ViDQo+PiBwYXJhZ3JhcGgp LiBlLmcuDQo+PiBPTEQgOiAgICAgIFRoZSBlcnJvciBoYW5kbGluZyBvZiB0aGUgZm9sbG93aW5n IGNhc2UgZGVzY3JpYmVkIGluIFNlY3Rpb24gNi4zIG9mDQo+PiBbUkZDNDI3MV0gaXMgcmV2aXNl ZA0KPj4gTkVXOiAyKSBUaGUgZXJyb3IgaGFuZGxpbmcgb2YgdGhlIGZvbGxvd2luZyBjYXNlIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDYuMyBvZg0KPj4gW1JGQzQyNzFdIGlzIHJldmlzZWQNCj4+IA0K Pj4gLS0tLQ0KPj4gRWRpdG9yaWFsOiAiVGhpcyBkb2N1bWVudCBwYXJ0aWFsbHkgcmV2aXNlcyBb Li4uXSBwcm92aWRlcyBndWlkZWxpbmVzIGZvciB0aGUNCj4+IGF1dGhvcnMgb2YgZG9jdW1lbnRz IGRlZmluaW5nIG5ldyBhdHRyaWJ1dGVzLiINCj4+IA0KPj4gSSB3b3VsZCBwcm9wb3NlIHRvIGdy b3VwIHRoZXNlIGd1aWRlbGluZXMgaW4gYSBzcGVjaWZpYyBwYXJhZ3JhcGguIEluZGVlZCwNCj4+ IHN1Y2ggZ3VpZGVsaW5lcyBhcmUgZXhwZWN0ZWQgdG8gYmUgcmVmZXJyZWQgdG8gYW5kIHJlYWQg Zm9yIGVhY2ggbmV3IElEUg0KPj4gc3BlYy4gKHdoaWxlIGN1cnJlbnRseSwgdGhvc2UgZ3VpZGVs aW5lcyBhcmUgYSBiaXQgc3ByZWFkIGluIHRoZSBkb2N1bWVudCkNCj4+IC0tLS0NCj4+IKHsIDMu My4gVHlwZWQgTkxSSQ0KPj4gDQo+PiAiICAgQSBCR1Agc3BlYWtlciBhZHZlcnRpc2luZyBzdXBw b3J0IGZvciBzdWNoIGEgdHlwZWQgYWRkcmVzcyBmYW1pbHkNCj4+ICAgTVVTVCBoYW5kbGUgcm91 dGVzIHdpdGggdW5yZWNvZ25pemVkIE5MUkkgdHlwZXMgd2l0aGluIHRoYXQgYWRkcmVzcw0KPj4g ICBmYW1pbHkgYnkgZGlzY2FyZGluZyB0aGVtLCB1bmxlc3MgdGhlIHJlbGV2YW50IHNwZWNpZmlj YXRpb24gZm9yIHRoYXQNCj4+ICAgYWRkcmVzcyBmYW1pbHkgc3BlY2lmaWVzIG90aGVyd2lzZS4i DQo+PiANCj4+IFRoZSBsYXRlc3QgcGFydCBzZWVtcyBzdHJhbmdlOiAiIHVubGVzcyB0aGUgcmVs ZXZhbnQgc3BlY2lmaWNhdGlvbiBmb3IgdGhhdA0KPj4gYWRkcmVzcyBmYW1pbHkgc3BlY2lmaWVz IG90aGVyd2lzZSIuIEluZGVlZCwgZ2l2ZW4gdGhhdCB0aGUgTkxSSSB0eXBlcyBhcmUNCj4+IHVu cmVjb2duaXplZCBieSB0aGUgQkdQIHNwZWFrZXIsIGl0IHNlZW1zIHN0cmFuZ2UgdG8gbWFuZGF0 ZSBoaW0gdG8NCj4+IGNvbXBseSB3aXRoIHRoZSBzcGVjIHdoaWNoIGlzIHVua25vd24gdG8gaGlt Lg0KPj4gLS0tLS0tDQo+PiBFZGl0b3JpYWwvbml0IHBpY2tpbmc6IKHsNS4xMS81LjEyICYgNS41 IGhhdmUgY2hvc2VuIGEgZGlmZmVyZW50IHdheSBvZg0KPj4gZXhwcmVzc2luZyB0aGUgc2FtZSB0 aGluZy4goew1LjUgZ3JvdXBzIHBlciAodHlwZSBvZiBlcnJvciAobWFsZm9ybWVkIG9yDQo+PiBp bGxlZ2l0aW1hdGUgcHJlc2VuY2UpICwgdHlwZSBvZiBzZXNzaW9uKSB3aGlsZSCh7DUuMTEvNS4x MiBncm91cHMgcGVyICh0eXBlIG9mDQo+PiBzZXNzaW9uLCB0eXBlIG9yIGVycm9yKS4gUGVyc29u YWxseSBJIGhhdmUgYSBwcmVmZXJlbmNlIGZvciB0aGUgoew1LjExLzUuMTINCj4+IHdheSwgd2hp Y2ggaXMgbW9yZSBjb25jaXNlLg0KPj4gDQo+PiAtLS0tLS0NCj4+IFdoYXQncyBuZXh0IGFmdGVy IFdHTEMgPw0KPj4gT3ZlciB0aGUgbGFzdCB5ZWFycywgdGhlIGRyYWZ0IGhhcyBiZWVuIHJlZ3Vs YXJseSB1cGRhdGVkLCBzaG93aW5nIHRoYXQgdGhpcw0KPj4gc3ViamVjdCBpcyBhIGxhcmdlIGFu ZCBkaWZmaWN1bHQuIFVubGVzcyB3ZSBoYXZlIGEgcmVhc29uIHRvIGJlbGlldmUgdGhhdCBub3cN Cj4+IHRoZSBzcGVjIGlzIGZpbmFsIGFuZCBwZXJmZWN0LCB3aGF0IGlzIHRoZSBwbGFuIGZvciB0 aGUgbmV4dCBzcGVjIGNoYW5nZSAoaW4gMTINCj4+IG1vbnRocyA7LSkgKT8gQXJlIHdlIHJlYWR5 L29rIHRvIGNyZWF0ZSBhIGJpcyBkcmFmdD8NCj4+IC0tLS0tLQ0KPj4gDQo+PiBUaGFua3MsDQo+ PiBSZWdhcmRzLA0KPj4gQnJ1bm8NCj4+IA0KPj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+PiBGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFN1c2FuIEhhcmVzDQo+Pj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMDcsIDIwMTQgODoz MSBQTQ0KPj4+IFRvOiAnSm9obiBHLiBTY3VkZGVyJzsgJ2lkckBpZXRmLiBvcmcnDQo+Pj4gU3Vi amVjdDogW0lkcl0gMiBXZWVrIFdHIExDOiBkcmFmdC1pZXRmLWlkci1lcnJvci1oYW5kbGluZy0w Ny50eHQNCj4+PiANCj4+PiBKb2huOg0KPj4+IA0KPj4+IENvbmdyYXR1bGF0aW9ucyBvbiBwdWJs aXNoaW5nIGRyYWZ0IG9mIGRyYWZ0LWlldGYtaWRyLWVycm9yLWhhbmRsaW5nLTA3LnR4dC4NCj4+ PiBUaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBMQyBzdGFydGluZyB0b2RheSAoNS83LzE0KSwgYW5k IGVuZGluZw0KPj4+IDUvMjEvMTQuICBJbiB5b3VyIGNvbW1lbnRzIHBsZWFzZSBpbmRpY2F0ZSwg c3VwcG9ydC9ubyBzdXBwb3J0IGZvciB0aGUNCj4+IFdHIExDLg0KPj4+IA0KPj4+IFBsZWFzZSBh bHNvIGluZGljYXRlIGlmIHlvdSBrbm93IGlmIElQUiBieSByZXNwb25kaW5nLg0KPj4+IA0KPj4+ IFN1ZQ0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogSWRy IFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2huIEcuIFNjdWRk ZXINCj4+PiBTZW50OiBXZWRuZXNkYXksIE1heSAwNywgMjAxNCAyOjE3IFBNDQo+Pj4gVG86IGlk ckBpZXRmLiBvcmcNCj4+PiBTdWJqZWN0OiBSZTogW0lkcl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1pZHItZXJyb3ItaGFuZGxpbmctMDcudHh0DQo+Pj4gDQo+Pj4gRm9sa3MsDQo+Pj4gDQo+Pj4g Q29tcGFyZWQgdG8gLTA2LCB0aGlzIHZlcnNpb24gbGlzdHMgYSBjb3VwbGUgbW9yZSBOTFJJIChp biljb3JyZWN0bmVzcw0KPj4+IGNyaXRlcmlhIGluIFMuIDMuMiBhcyBkaXNjdXNzZWQgYXQgdGhl IGxhc3QgSUVURiBtZWV0aW5nLCBhZGRzIFMuIDMuMw0KPj4+IG9uIHRoZSBoYW5kbGluZyBvZiB0 eXBlZCBOTFJJIChzdWNoIGFzIGZvciBNVlBOIGFuZCBFVlBOKSwgbWFrZXMgYW4NCj4+PiBlZGl0 b3JpYWwgY2xhcmlmaWNhdGlvbiByZWdhcmRpbmcgd2hlbiBhIHNlc3Npb24gbXVzdCBiZSByZXNl dCwgYW5kDQo+Pj4gcmVtb3ZlcyBBcHBlbmRpeCBBLiBUaGUgZGVsZXRpb24gb2YgQXBwZW5kaXgg QSB3YXMgYmVjYXVzZSBpdCB3YXMNCj4+PiB0aGVyZSBmb3IgcHVycG9zZXMgb2YgZXhwbGFuYXRp b24gaW4gdGhlIGVhcmx5IHZlcnNpb25zIG9mIHRoZSBkcmFmdCwNCj4+PiBidXQgYXQgdGhpcyBw b2ludCBldmVyeW9uZSBzZWVtcyB0byBnZXQgdGhlIHBvaW50IGFuZCB0aGVyZSBkb2Vzbid0DQo+ Pj4gc2VlbSB0byBiZSBhbnkgbmVlZCB0byBjbHV0dGVyIHVwIHRoZSBldmVudHVhbCBSRkMgd2l0 aCBpdC4NCj4+PiANCj4+PiBXaXRoIHRoaXMgcmV2aXNpb24gdGhlIGF1dGhvcnMgdGhpbmsgdGhl IGRvY3VtZW50IGlzIHJlYWR5IGZvciB3b3JraW5nDQo+Pj4gZ3JvdXAgbGFzdCBjYWxsLg0KPj4+ IA0KPj4+IFRoYW5rcywNCj4+PiANCj4+PiAtLUpvaG4NCj4+PiANCj4+Pj4gT24gTWF5IDcsIDIw MTQsIGF0IDI6MDggUE0sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4+Pj4gDQo+ Pj4+IA0KPj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+PiBkaXJlY3Rvcmllcy4NCj4+Pj4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50ZXItRG9tYWluIFJvdXRpbmcgV29ya2luZyBHcm91cA0K Pj4+PiBvZiB0aGUNCj4+PiBJRVRGLg0KPj4+PiANCj4+Pj4gICAgICAgVGl0bGUgICAgICAgICAg IDogUmV2aXNlZCBFcnJvciBIYW5kbGluZyBmb3IgQkdQIFVQREFURSBNZXNzYWdlcw0KPj4+PiAg ICAgICBBdXRob3JzICAgICAgICAgOiBFbmtlIENoZW4NCj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgSnVuaXBlciBOZXR3b3Jrcw0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBQcmFk b3NoIE1vaGFwYXRyYQ0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBLZXl1ciBQYXRlbA0K Pj4+PiAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWlkci1lcnJvci1oYW5kbGluZy0w Ny50eHQNCj4+Pj4gICAgUGFnZXMgICAgICAgICAgIDogMTMNCj4+Pj4gICAgRGF0ZSAgICAgICAg ICAgIDogMjAxNC0wNS0wNw0KPj4+PiANCj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+ICBBY2NvcmRpbmcg dG8gdGhlIGJhc2UgQkdQIHNwZWNpZmljYXRpb24sIGEgQkdQIHNwZWFrZXIgdGhhdCByZWNlaXZl cw0KPj4+PiAgYW4gVVBEQVRFIG1lc3NhZ2UgY29udGFpbmluZyBhIG1hbGZvcm1lZCBhdHRyaWJ1 dGUgaXMgcmVxdWlyZWQgdG8NCj4+Pj4gIHJlc2V0IHRoZSBzZXNzaW9uIG92ZXIgd2hpY2ggdGhl IG9mZmVuZGluZyBhdHRyaWJ1dGUgd2FzIHJlY2VpdmVkLg0KPj4+PiAgVGhpcyBiZWhhdmlvciBp cyB1bmRlc2lyYWJsZSBhcyBhIHNlc3Npb24gcmVzZXQgd291bGQgaW1wYWN0IG5vdCBvbmx5DQo+ Pj4+ICByb3V0ZXMgd2l0aCB0aGUgb2ZmZW5kaW5nIGF0dHJpYnV0ZSwgYnV0IGFsc28gb3RoZXIg dmFsaWQgcm91dGVzDQo+Pj4+ICBleGNoYW5nZWQgb3ZlciB0aGUgc2Vzc2lvbi4gIFRoaXMgZG9j dW1lbnQgcGFydGlhbGx5IHJldmlzZXMgdGhlDQo+Pj4+ICBlcnJvciBoYW5kbGluZyBmb3IgVVBE QVRFIG1lc3NhZ2VzLCBhbmQgcHJvdmlkZXMgZ3VpZGVsaW5lcyBmb3IgdGhlDQo+Pj4+ICBhdXRo b3JzIG9mIGRvY3VtZW50cyBkZWZpbmluZyBuZXcgYXR0cmlidXRlcy4gIEZpbmFsbHksIGl0IHJl dmlzZXMNCj4+Pj4gIHRoZSBlcnJvciBoYW5kbGluZyBwcm9jZWR1cmVzIGZvciBhIG51bWJlciBv ZiBleGlzdGluZyBhdHRyaWJ1dGVzLg0KPj4+PiANCj4+Pj4gIFRoaXMgZG9jdW1lbnQgdXBkYXRl cyBlcnJvciBoYW5kbGluZyBmb3IgUkZDcyAxOTk3LCA0MjcxLCA0MzYwLCA0NDU2LA0KPj4+PiAg NDc2MCwgYW5kIDU3MDEuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWVycm9yLWhhbmRsaW5nLw0KPj4+PiANCj4+Pj4g VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pj4+IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRyLWVycm9yLWhhbmRsaW5nLTA3DQo+ Pj4+IA0KPj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6DQo+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaWRy LWVycm9yLWhhbmRsaW5nLTA3DQo+Pj4+IA0KPj4+PiANCj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+Pj4gc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0DQo+Pj4gdG9vbHMuaWV0Zi5vcmcuDQo+Pj4+IA0KPj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+IGZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBJZHIgbWFpbGluZyBsaXN0DQo+Pj4+IElk ckBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lk cg0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gSWRyIG1haWxpbmcgbGlzdA0KPj4+IElkckBpZXRmLm9yZw0KPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+Pj4gDQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBJZHIgbWFpbGluZyBsaXN0 DQo+Pj4gSWRyQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pZHINCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gX19fX18NCj4+IA0KPj4gQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+ PiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzDQo+PiBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXoNCj4+IGxl IHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcw0KPj4gbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZQ0KPj4gcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp Lg0KPj4gDQo+PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KPj4gaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLA0KPj4gdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUN Cj4+IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPj4gQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJl ZW4NCj4+IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4+IFRoYW5rIHlvdS4NCj4+ IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IElkciBtYWlsaW5nIGxpc3QNCj4+IElkckBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZHINCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IENlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KPiBwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cg0KPiBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLA0KPiBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+IA0KPiBU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0K PiB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gSWRyIG1haWxpbmcgbGlzdA0KPiBJZHJAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCg== From nobody Tue May 13 09:32:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A6C1A011A for ; Tue, 13 May 2014 09:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HdTJjUyqXWu for ; Tue, 13 May 2014 09:32:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id EB6E11A0117 for ; Tue, 13 May 2014 09:32:42 -0700 (PDT) Received: from jcottingham-sslvpn-nc.jnpr.net (66.129.241.12) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.929.12; Tue, 13 May 2014 16:32:35 +0000 Content-Type: text/plain; charset="iso-8859-2" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011EC2C8@EX01.swan.local> Date: Tue, 13 May 2014 09:32:25 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140507180846.28346.38054.idtracker@ietfa.amsl.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EC090@EX01.swan.local> <4E44A310-BE4D-4016-852F-351C100C7728@juniper.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011EC2C8@EX01.swan.local> To: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: DM2PR08CA006.namprd08.prod.outlook.com (10.141.52.164) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(24454002)(377454003)(51704005)(15202345003)(20776003)(66066001)(80022001)(50226001)(47776003)(77982001)(2009001)(102836001)(89996001)(93916002)(92726001)(83716003)(4396001)(57306001)(99396002)(46102001)(83072002)(88136002)(85852003)(36756003)(77156001)(19580405001)(53416003)(83322001)(19580395003)(101416001)(50986999)(15975445006)(76482001)(81542001)(62966002)(87286001)(86362001)(79102001)(81342001)(76176999)(82746002)(33656001)(50466002)(74662001)(42186004)(74502001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB722; H:jcottingham-sslvpn-nc.jnpr.net; FPR:2782C1F6.CF01FEA.B1D165FF.92E5D379.202E8; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/09L3Tudy5mR3K2nMHZTEBUzntbU Cc: "idr@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:32:45 -0000 [removed internet-drafts and i-d-announce from cc] Adam, Thanks for your reply. On May 13, 2014, at 4:03 AM, Vitkovsk=FD Adam = wrote: ... > Sorry for the bad choice of words I thought that the updates might = start looping in remote ASes.=20 > However now I see that the ORIGINATOR_ID and CLUSTER_LIST attributes, = even if deleted on ingress from an eBGP session, are going to be = recreated by the RRs(clusters) in the remote AS when the update is = propagated further so no loops can occur in the remote ASes.=20 Great -- this means draft-ietf-idr-error-handling-07 is OK. > However I'm not sure how the ORIGINATOR_ID should be recreated (local = router id or the eBGP peer ip address) >=20 > So actually the worst that can happen is asymmetric routing or = sub-optimal path selection if one relies on originator ID or the cluster = list length for best path selection.=20 >=20 > Example: > AS-D receives an update for X via AS-B and AS-C.=20 > AS-B is a big AS so the update made it through several clusters when = propagated across.=20 > AS-C is a small AS so the update crossed only one cluster on its way = to AS-D.=20 > Now let's assume the CLUSTER_LIST attribute is deleted on ingress to = AS-D on a malformed update from AS-B.=20 > For PEs in AS-D the path via AS-C now appears to be less preferred = because it has a longer CLUSTER_LIST.=20 I don't think so -- in either case, any CLUSTER_LIST received over an = EBGP session MUST be removed, so both AS-C and AS-B's routes will be = considered in AS-D to have no CLUSTER_LIST. I actually wrote a draft that relates to this some time ago but didn't = progress it, draft-scudder-idr-ebgp-rr-02, = http://www.ietf.org/proceedings/85/slides/slides-85-idr-4.pdf. I'd be = willing to resurrect it if the WG thinks it would be useful. I don't = think it needs a lot more work (possibly no more work). Regards, --John= From nobody Tue May 13 09:36:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC4C1A012E for ; Tue, 13 May 2014 09:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_SUMOF=1] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXMHg6YHMdxy for ; Tue, 13 May 2014 09:36:30 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) by ietfa.amsl.com (Postfix) with ESMTP id 17C641A0131 for ; Tue, 13 May 2014 09:36:28 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WkFgh-0007KM-Mo for idr@ietf.org; Tue, 13 May 2014 16:36:19 +0000 From: "Chris Hall" To: "'idr@ietf. org'" References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6937_1399968671_5371D39F_6937_5572_1_53C29892C857584299CBF5D05346208A07148FB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <6937_1399968671_5371D39F_6937_5572_1_53C29892C857584299CBF5D05346208A07148FB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Tue, 13 May 2014 17:36:14 +0100 Organization: Highwayman Message-ID: <053001cf6ec9$77f15420$67d3fc60$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGj8fXud1vrpGiTRuOtdk5WCitkjwFvt1VdAZXd5gubfPoCYA== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NOn2c-sdPLxGbw38KxMDvGqmnJo Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:36:32 -0000 Bruno Decraene wrote (on Tue 13-May-2014 at 09:11 +0100): .... > In the current version of the draft, attribute flags that conflict > with the attribute type code are handled with "treat-as-withdraw". > This good IMO. Likewise. > However, an exception is done for 2 attributes: MP_(UN)REACH_NLRI. > For those 2 attributes, such flag error is handled with "Session > reset". I don't recall much debate on this point so I'd like to > initiate a discussion on this point. There is another exception: a second MP_REACH_NLRI or a second MP_UNREACH_NLRI are cause for session-reset, but the receiver MUST attribute-discard the second or subsequent instances of all other attribute types. The draft states that for treat-as-withdraw to be applicable, the NLRI "need to be successfully parsed". Consistent with that, the rules for NLRI require them to be "perfectly-formed". This high threshold seems reasonable: the NLRI are required for treat-as-withdraw to work, so errors in the NLRI are not the same as errors in other attributes. Though if the receiver sees two or more perfectly-formed MP_REACH_NLRI, it could treat-as-withdraw without much difficulty ? But, perhaps there are some lapses which cannot be forgiven. If the MP_xx_NLRI are always the first attributes, and are perfectly-formed, then any error "downstream" can be treated-as-withdraw with a high degree of confidence that *all* (my emphasis) NLRI have been "successfully parsed". If only that was all there is to it. [In passing: if there is an MP_REACH_NLRI and/or NLRI, the first attribute after any leading MP_xx_NLRI ought to be the ORIGIN attribute. If so, and if it is also perfectly-formed, we may be (even) more confident that the MP_xx_NLRI are, indeed, perfectly-formed -- i.e. the agreement between the attribute length and the sum of the prefix lengths is (even) less likely to be just a happy coincidence.] --------------------------------- So far, so good... to qualify for treat-as-withdraw, it is clear that all NLRI which are found must be perfectly-formed. BUT, it is less than clear how to find all the NLRI, and even less clear how to know that all the NLRI have been found... ...where an MP_xx_NLRI is not found, we may conclude (a) that no such attribute was sent, or (b) that one might have been sent, but it is buried under the error(s) we are trying to handle -- "lost-NLRI" -- depending (inter alia) on how badly mangled the rest of the attributes are. The sender may intend to send MP_xx_NLRI first -- as recommended by the draft -- but the receiver cannot know that. In any case, a sender may fail to live up to its intentions. Hence, the receiver "MUST be still be prepared to receive these fields in any position". I assume being "prepared" includes applying all the new error handling ? Suppose the receiver sees a LOCAL_PREF attribute of length 2000, which for iBGP SHALL be treated-as-withdraw (see 3.1 and 5.5). If the sender is following the old rule of sending attributes in ascending type number order, then there may be lost-NLRI -- unless, of course, the sender has simply "had a moment" and really sent 2000 octets of LOCAL_PREF. The draft does not, as far as I can see, address the risk of lost-NLRI. Is it the draft's intention to leave this as (an interesting) problem for the implementer ? There are any number of heuristics that may be applied to this problem. It would be helpful if, in practice, the vast majority of implementations only ever send one set of NLRI per message. It helps a bit if, in practice, MP_xx_REACH attributes only appear in messages where both the Withdraw Routes and NLRI parts are empty. Does anybody know if either of these is the case ? [FWIW: if the sender sent an MP_REACH_NLRI as the first attribute, and later a 2000 octet LOCAL_PREF, it is assumed it didn't send further MP_REACH_NLRI (now lost) which would otherwise be cause for session-reset. You might say that sending more than one MP_REACH_NLRI would be an act of complete madness and may be discounted, while sending a 2000 octet LOCAL_PREF is merely eccentric... I couldn't possibly comment.] Chris --------------------------------- PS: I note that if the receiver sees a LOCAL_PREF attribute of length 500 in an eBGP session, then it SHALL be treated as attribute-discard. If the attributes exactly fit in the Total Attribute Length, then prima facie all their lengths are correct -- looks like a sort of checksum. In which case, the draft deems a 500 octet LOCAL_PREF to be an outsize attribute, even though LOCAL_PREF should not be there in the first place and quacks (loudly) like an error. If nothing else triggers treat-as-withdraw (or session-reset) then the receiver SHALL proceed to use the routes... complete nonsense notwithstanding; even though a 500 octet LOCAL_PREF attribute for iBGP would be treat-as-withdraw. Really ? From nobody Tue May 13 09:53:58 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043A21A013E for ; Tue, 13 May 2014 09:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVbZkzvPGb-4 for ; Tue, 13 May 2014 09:53:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id CDCB11A012E for ; Tue, 13 May 2014 09:53:53 -0700 (PDT) Received: from jcottingham-sslvpn-nc.jnpr.net (66.129.241.12) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.929.12; Tue, 13 May 2014 16:53:39 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <053001cf6ec9$77f15420$67d3fc60$@highwayman.com> Date: Tue, 13 May 2014 09:53:29 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <535FA04C-4EC0-4111-8E68-D2DF3F1C8000@juniper.net> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6937_1399968671_5371D39F_6937_5572_1_53C29892C857584299CBF5D05346208A07148FB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <053001cf6ec9$77f15420$67d3fc60$@highwayman.com> To: Chris Hall X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: DM2PR06CA008.namprd06.prod.outlook.com (10.141.96.38) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(199002)(24454002)(189002)(62966002)(76482001)(81542001)(85852003)(88136002)(36756003)(19580405001)(53416003)(77156001)(83072002)(46102001)(50986999)(83322001)(19580395003)(101416001)(82746002)(76176999)(33656001)(74502001)(50466002)(42186004)(74662001)(86362001)(87286001)(79102001)(81342001)(46406003)(66066001)(80022001)(47776003)(50226001)(20776003)(97756001)(92726001)(83716003)(93916002)(57306001)(99396002)(4396001)(102836001)(89996001)(77982001)(2009001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB722; H:jcottingham-sslvpn-nc.jnpr.net; FPR:F484C597.83F6D389.B6E37DAB.40E62B6B.20239; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/0TmyYFYqkk9u9WMkkrehjc2W8z4 Cc: "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:53:56 -0000 Chris, To address one point from your long and interesting message: On May 13, 2014, at 9:36 AM, Chris Hall = wrote: > There are any number of heuristics that may be applied to this > problem. It would be helpful if, in practice, the vast majority of > implementations only ever send one set of NLRI per message. It helps > a bit if, in practice, MP_xx_REACH attributes only appear in messages > where both the Withdraw Routes and NLRI parts are empty. Does anybody > know if either of these is the case ? I (strongly) believe these to be common practice. I'm confident of it = for the code base I've currently got access to, but can't speak = authoritatively for others of course. Maybe other folks will chime in.=20= There is nothing to stop us from explicitly mandating this practice in = the future. However for some indefinite time to come we'll still need to = be prepared to deal with the deprecated behavior, so I'm not sure it = makes any practical difference for the error-handling draft. It's all a bit of a tightwire act, as your examples demonstrate. --John= From nobody Tue May 13 10:08:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529471A011E for ; Tue, 13 May 2014 10:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w7LILY690CA for ; Tue, 13 May 2014 10:08:18 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) by ietfa.amsl.com (Postfix) with ESMTP id D5AAA1A008E for ; Tue, 13 May 2014 10:08:17 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WkGBU-0007L3-5i for idr@ietf.org; Tue, 13 May 2014 17:08:08 +0000 From: "Chris Hall" To: References: <20140507180846.28346.38054.idtracker@ietfa.amsl.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EC090@EX01.swan.local> <4E44A310-BE4D-4016-852F-351C100C7728@juniper.net> <61DC6BC4ABA10E4489D4A73EBABAC18B011EC2C8@EX01.swan.local> In-Reply-To: Date: Tue, 13 May 2014 18:08:03 +0100 Organization: Highwayman Message-ID: <053701cf6ecd$e97677c0$bc636740$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHf8CrNPENsm0VL6yLMHO4rG1ycjAKNYHqQAhxzZq4CLrsLwAItN9vdmtWFHwA= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/aLNjj6jurhsOUOImPaYb0hZ9ggE Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 17:08:19 -0000 I note that Section 4, Operational Considerations, discusses the issue of the potential dangers of "attribute-discard", and states that: "if the attribute in question has or may have an effect on route selection or installation, the presumption is that discarding it is unsafe" Earlier, in Section 2, where repeat instances of attributes are considered: "all occurrences other than the first one SHALL be discarded" Faced with two versions of, say, AS_PATH, choosing one over the other may affect route selection. Is there an inconsistency here ? It doesn't seem to me that a blanket "attribute-discard" is a Good Thing. [On the balance of probabilities, I'd say that a second AS_PATH is most likely to be a symptom of some deeper issue with the message. Similarly with other "well-known" attributes. But that's not entirely the point here.] Chris From nobody Tue May 13 11:48:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225421A0131 for ; Tue, 13 May 2014 11:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEQMqDwbDhN1 for ; Tue, 13 May 2014 11:48:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 146EC1A010C for ; Tue, 13 May 2014 11:48:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B9364C1FF; Tue, 13 May 2014 14:48:37 -0400 (EDT) Date: Tue, 13 May 2014 14:48:37 -0400 From: Jeffrey Haas To: bruno.decraene@orange.com Message-ID: <20140513184837.GU13387@pfrc> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup> <87358378-754C-44AD-817E-4FE28C0A9E14@juniper.net> <20299_1399650562_536CF902_20299_11373_1_53C29892C857584299CBF5D05346208A07147242@PEXCVZYM11.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20299_1399650562_536CF902_20299_11373_1_53C29892C857584299CBF5D05346208A07147242@PEXCVZYM11.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/MlVK--yprfDWzg5y__adnomJ04o Cc: Hares Susan , "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 18:48:45 -0000 On Fri, May 09, 2014 at 03:49:21PM +0000, bruno.decraene@orange.com wrote: > > > What's next after WGLC ? > > > Over the last years, the draft has been regularly updated, showing that this > > subject is a large and difficult. Unless we have a reason to believe that now > > the spec is final and perfect, what is the plan for the next spec change (in 12 > > months ;-) )? Are we ready/ok to create a bis draft? > > > > IMO, yes. Of course we could continue error-handling as a seemingly eternal > > draft, but I think there is some value in saying "close enough" and graduating > > it to RFC, especially for implementors that are less steeped in the WG and > > don't necessarily have the background to distinguish between Internet > > Drafts that are really *drafts* and those that are de-facto standards. > > Thanks for the clarification. I support moving forward the current draft to RFC. I was just checking whether the authors were ok with continuing the work if needed The WG wiki also provides a good place for documenting "best practices" on such things. -- Jeff From nobody Tue May 13 13:06:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6151D1A019F for ; Tue, 13 May 2014 13:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-n7Xrvwgtq4 for ; Tue, 13 May 2014 13:05:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F271C1A01B3 for ; Tue, 13 May 2014 13:05:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9E743C1FF; Tue, 13 May 2014 16:05:49 -0400 (EDT) Date: Tue, 13 May 2014 16:05:49 -0400 From: Jeffrey Haas To: Ondrej Zajicek Message-ID: <20140513200549.GV13387@pfrc> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20140511100316.GA12659@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140511100316.GA12659@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/2QZBZnJX08p54v6brwbDYVwqkLg Cc: Susan Hares , idr@ietf.org Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 20:05:58 -0000 Ondrej, On Sun, May 11, 2014 at 12:03:16PM +0200, Ondrej Zajicek wrote: > 5.2. AS_PATH > > The draft says 'The error conditions for the attribute have been > defined in [RFC4271]'. Unfortunately, RFC 4271 is rather vague > about error conditions for AS_PATH. It says just: > > "The AS_PATH attribute is checked for syntactic correctness. If the > path is syntactically incorrect, then the Error Subcode MUST be set > to Malformed AS_PATH." > > Without exactly specifying the syntactic correctness of AS_PATH. > Although most if it is intuitive and self-explanatory, there are > several issues (AFAIK) not addressed anywhere: > > 1) Is incorrect AS_PATH with unknown (undefined in RFC 4271) > segment types (i.e. different ones than AS_SET or AS_SEQUENCE)? > I would guess yes unless receiver knows these new types (like > AS_CONFED_* from RFC 5065), but 'no' can be also viewed as > reasonable possibility. A few issues are identified above: The error-handling draft doesn't refer to to RFC 5065. If you pedantically go by the text above, only non-confederation is supported. Syntactic checks are probably what we want here. We should have a section for semantic checks on AS_PATH. Suggested text: The error conditions for the attribute have been defined in [RFC4271], and have been extended by [RFC5065]. An UPDATE message with a malformed AS_PATH attribute SHALL be handled using the approach of "treat-as-withdraw An UPDATE message containing a syntactically valid AS_PATH that is semantically invalid (i.e. an unrecognized path segment type) SHALL be handled using the approach of "treat-as-withdraw". It's my reading that RFC 5065, sec. 5 is covered in the error handling document by referring back to malformed behavior. (Assuming you presume the error handling document is a semantic override of RFC 4271. Otherwise we need explicit text overriding that behavior. I leave that interpretation to the more pedantic of the working group.) > 2) Is incorrect AS_PATH that cannot be generated by rules from > RFC 4271 5.1.2? E.g. path containing two small sequence > segments? I would guess no, but yes is also reasonable > possibility (if your view on syntax and grammar is more > generative than descriptive). This would be hazardous. Forgiving in what you receive, strict in what you send and all that. Plus, there was an odd idea circulating IDR a while ago to try to pad AS_SET length in route selection by generating tiny segments a while ago. (Probably not going to work.) > 5.3. NEXT_HOP > > Also a bit vague. RFC 4271 6.3 defines syntactical and > semantical correctness for NEXT_HOP attribute. A syntactically > incorrect attribute is obviously malformed, but it is not clear > whether the attribute should be considered maformed if it is > just semantically incorrect. Part 2 of the draft suggests it > shouldn't (as it does not specify a session reset in RFC 4271). > > I would suggest to replace 'The error conditions for the > NEXT_HOP attribute ...' with 'The attribute is considered > malformed if it is syntactically incorrect according to RFC > 4271', if that is what was meant. MP_NEXTHOP becomes trickier with features that play with the nexthop length. I believe those are currently covered by capability. Semantic incorrectness should probably result in treat-as-withdraw, IMO. We can parse the packet, it just looks crazy. -- Jeff From nobody Tue May 13 13:07:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D081E1A01CB for ; Tue, 13 May 2014 13:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLRoTlsbHiJ7 for ; Tue, 13 May 2014 13:07:33 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 377561A01A6 for ; Tue, 13 May 2014 13:07:28 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id EDF7CC1FF; Tue, 13 May 2014 16:07:21 -0400 (EDT) Date: Tue, 13 May 2014 16:07:21 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140513200721.GW13387@pfrc> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/5h7RpKxPKA8xLz_z51N7vQ6Vba4 Cc: "'idr@ietf. org'" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 20:07:35 -0000 On Wed, May 07, 2014 at 02:31:15PM -0400, Susan Hares wrote: > Congratulations on publishing draft of draft-ietf-idr-error-handling-07.txt. > This begins a 2 week WG LC starting today (5/7/14), and ending 5/21/14. In > your comments please indicate, support/no support for the WG LC. I support that the document is generally ready, although Ondrej has pointed out some details that probably should be resolved before WGLC completes. Juniper implements a form of this draft, although as John points out the most recent changes will require some minor work. -- Jeff From nobody Tue May 13 16:23:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE73F1A0205 for ; Tue, 13 May 2014 16:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmjIIHUseDFa for ; Tue, 13 May 2014 16:22:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0092.outbound.protection.outlook.com [207.46.100.92]) by ietfa.amsl.com (Postfix) with ESMTP id E125C1A01E5 for ; Tue, 13 May 2014 16:22:56 -0700 (PDT) Received: from jcottingham-sslvpn-nc.jnpr.net (66.129.241.12) by BY2PR05MB726.namprd05.prod.outlook.com (10.141.223.19) with Microsoft SMTP Server (TLS) id 15.0.944.11; Tue, 13 May 2014 23:22:49 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <053001cf6ec9$77f15420$67d3fc60$@highwayman.com> Date: Tue, 13 May 2014 16:22:34 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <0002C0B9-A7FA-4C39-AFA1-3F2EC8ED9EE5@juniper.net> References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6937_1399968671_5371D39F_6937_5572_1_53C29892C857584299CBF5D05346208A07148FB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <053001cf6ec9$77f15420$67d3fc60$@highwayman.com> To: Chris Hall X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR08CA017.namprd08.prod.outlook.com (10.141.30.37) To BY2PR05MB726.namprd05.prod.outlook.com (10.141.223.19) X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(164054003)(377454003)(199002)(189002)(74502001)(33656001)(4396001)(74662001)(20776003)(64706001)(31966008)(79102001)(19580405001)(80022001)(46406003)(83322001)(66066001)(88136002)(19580395003)(47776003)(76482001)(42186004)(69596002)(97756001)(57306001)(50466002)(87976001)(36756003)(81156002)(50226001)(77982001)(99396002)(89996001)(2009001)(21056001)(53416003)(83716003)(23726002)(87286001)(46102001)(92566001)(92726001)(86362001)(83072002)(85852003)(77156001)(102836001)(50986999)(101416001)(82746002)(76176999)(62966002)(81542001)(81342001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB726; H:jcottingham-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/SfvNz5CootLGio05LiqPGQwVElQ Cc: "idr@ietf. org" Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 23:22:58 -0000 Chris, On May 13, 2014, at 9:36 AM, Chris Hall = wrote: > The draft does not, as far as I can see, address the risk of > lost-NLRI. The draft doesn't provide a perfect solution to every arbitrary scenario = where NLRI might be lost while still producing a syntactically = well-formed UPDATE. The draft does try to strike a balance between prudence and avoidance of = ever-mounting complexity of error-detection heuristics to attempt to = detect ever less-likely problems.=20 > Is it the draft's intention to leave this as (an interesting) problem > for the implementer ? I guess if the implementor's paranoia is significantly greater than that = of the authors of the draft (and the WG members who assent to it, = assuming the WGLC concludes successfully), then you could say that.=20 We already mandate in the draft that the MP attributes MUST come first. = We could also mandate that the MP attributes MUST NOT be mixed with the = legacy encoding. Implementations would still have to be prepared to = receive updates with mixed MP and legacy NLRI of course, i.e. it = wouldn't be a NOTIFY-able offense, but by deprecating the behavior it = may help us some years down the road. Thanks, --John= From nobody Tue May 13 16:49:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81741A020A for ; Tue, 13 May 2014 16:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZdqC6VA2pGW for ; Tue, 13 May 2014 16:49:17 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) by ietfa.amsl.com (Postfix) with ESMTP id 5060F1A0208 for ; Tue, 13 May 2014 16:49:17 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WkMRZ-0007Nr-27 for idr@ietf.org; Tue, 13 May 2014 23:49:09 +0000 From: "Chris Hall" To: "'idr wg'" References: <008b01cf6a22$87ee08b0$97ca1a10$@ndzh.com> <20299_1399645112_536CE3B8_20299_6708_1_53C29892C857584299CBF5D05346208A07147104@PEXCVZYM11.corporate.adroot.infra.ftgroup> <6937_1399968671_5371D39F_6937_5572_1_53C29892C857584299CBF5D05346208A07148FB2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <053001cf6ec9$77f15420$67d3fc60$@highwayman.com> <535FA04C-4EC0-4111-8E68-D2DF3F1C8000@juniper.net> In-Reply-To: <535FA04C-4EC0-4111-8E68-D2DF3F1C8000@juniper.net> Date: Wed, 14 May 2014 00:49:03 +0100 Organization: Highwayman Message-ID: <056a01cf6f05$eed94610$cc8bd230$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGj8fXud1vrpGiTRuOtdk5WCitkjwFvt1VdAZXd5gsBo5bt/QCrpH4Lm2sSVGA= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vqVuHGfy2yUrrJBpDktoHz9Uk9E Subject: Re: [Idr] 2 Week WG LC: draft-ietf-idr-error-handling-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 23:49:18 -0000 John G. Scudder wrote (on Tue 13-May-2014 at 17:53 +0100): > On May 13, 2014, at 9:36 AM, Chris Hall wrote: > > > There are any number of heuristics that may be applied to this > > problem. It would be helpful if, in practice, the vast majority > > of implementations only ever send one set of NLRI per message. > > It helps a bit if, in practice, MP_xx_REACH attributes only > > appear in messages where both the Withdraw Routes and NLRI > > parts are empty. Does anybody know if either of these is the > > case ? > I (strongly) believe these to be common practice. I'm confident of > it for the code base I've currently got access to, but can't speak > authoritatively for others of course. Maybe other folks will chime > in. > > There is nothing to stop us from explicitly mandating this practice > in the future. However for some indefinite time to come we'll still > need to be prepared to deal with the deprecated behavior, so I'm not > sure it makes any practical difference for the error-handling draft. I agree that the draft should specify not only (1) that MP_xx_NLRI MUST be the first attribute, but also (2) that where MP_xx_NLRI is present it MUST be the only NLRI and (3) that MP_REACH_NLRI and MP_UNREACH_NLRI MUST NOT appear together. If the idr WG can testify to (2) and (3) being existing common practice, then the draft can observe that these nominally new requirement are already met by most/nearly all/virtually all BGP deployments. The joy of this is that the simplest possible approach to finding the NLRI is already sufficient and cannot be improved upon in most/nearly all/virtually all cases. The practical difference is that even with a badly broken message, the risk of doing an "incomplete" treat-as-withdraw is limited/small/negligible. Chris From nobody Tue May 13 17:26:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848B11A010E; Tue, 13 May 2014 17:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmnufduP6V37; Tue, 13 May 2014 17:26:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9050C1A012B; Tue, 13 May 2014 17:26:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140514002611.14599.94047.idtracker@ietfa.amsl.com> Date: Tue, 13 May 2014 17:26:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/XfSGLObFDwqZOqTG_tFXNEaHP-A Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 00:26:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Revised Error Handling for BGP UPDATE Messages Authors : Enke Chen Juniper Networks Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-08.txt Pages : 15 Date : 2014-05-13 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760 and 5701. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 13 17:28:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6CF1A012B for ; Tue, 13 May 2014 17:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLE-zAkEK4BX for ; Tue, 13 May 2014 17:28:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id CD57A1A0120 for ; Tue, 13 May 2014 17:28:08 -0700 (PDT) Received: from jcottingham-sslvpn-nc.jnpr.net (66.129.241.12) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.929.12; Wed, 14 May 2014 00:28:00 +0000 From: "John G. Scudder" Content-Type: multipart/alternative; boundary="Apple-Mail=_9FBF84D4-6145-4E5D-87A5-9C908E84F3AD" Message-ID: Date: Tue, 13 May 2014 17:27:54 -0700 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR07CA021.namprd07.prod.outlook.com (10.255.223.174) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Forefront-PRVS: 0211965D06 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(69224002)(20776003)(77982001)(92726001)(83716003)(92566001)(66066001)(84326002)(80022001)(50226001)(2009001)(102836001)(89996001)(57306001)(46102001)(4396001)(83072002)(99396002)(101416001)(88136002)(36756003)(85852003)(83322001)(53416003)(77156001)(87286001)(50986999)(81542001)(62966002)(76482001)(71186001)(79102001)(81342001)(31966008)(87976001)(512954002)(33656001)(82746002)(74662001)(86362001)(74502001)(42186004)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB722; H:jcottingham-sslvpn-nc.jnpr.net; FPR:747CFA1A.9DD0D72B.61F1AFBB.84E183AD.2022D; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ecQJRNapOizb0rWCJL98VaR61hA Subject: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 00:28:10 -0000 --Apple-Mail=_9FBF84D4-6145-4E5D-87A5-9C908E84F3AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Folks, The version I've just posted incorporates most of the suggestions = received during the WGLC to date, including: - Added to the rationale given in the introduction. - Refactored and cleaned up (the old) section 2 ("Revision to Base = Specification"). - Further restrictions on where and how NLRI fields can be sent (in = summary, don't mix your encodings and don't mix MP_REACH and = MP_UNREACH). These are believed to follow current practice. - Attribute length of zero generally disallowed, except in cases where = it actually makes sense (ATOMIC_AGGREGATE and sometimes AS_PATH). - New "Guidance for Authors of BGP Specifications" section. And various other bits of polish. Rfcdiff is your friend. Thanks for all the review so far, it's been very productive. The main = open issue I'm currently aware of is Bruno's regarding whether we should = stop being draconian with MP_{UN}REACH flags. For my part, I take no = strong position on this and am happy to follow whatever the WG consensus = is. --John= --Apple-Mail=_9FBF84D4-6145-4E5D-87A5-9C908E84F3AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Folks,

The version I've = just posted incorporates most of the suggestions received during the = WGLC to date, including:

- Added = to the rationale given in the introduction.
- Refactored and = cleaned up (the old) section 2 ("Revision to Base = Specification").
- = Further restrictions on where and how NLRI fields can be sent (in = summary, don't mix your encodings and don't mix MP_REACH and = MP_UNREACH). These are believed to follow current practice.
- Attribute length = of zero generally disallowed, except in cases where it actually makes = sense (ATOMIC_AGGREGATE and sometimes AS_PATH).
- New "Guidance for = Authors of BGP Specifications" section.

And various other bits of polish. Rfcdiff is your = friend.

Thanks for all the = review so far, it's been very productive. The main open issue I'm = currently aware of is Bruno's regarding whether we should stop being = draconian with MP_{UN}REACH flags. For my part, I take no strong = position on this and am happy to follow whatever the WG consensus = is.

--John= --Apple-Mail=_9FBF84D4-6145-4E5D-87A5-9C908E84F3AD-- From dbahadir@benocs.com Wed May 14 01:27:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521F31A0275 for ; Wed, 14 May 2014 01:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA0srh1i69fI for ; Wed, 14 May 2014 01:27:49 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id 93EFA1A0273 for ; Wed, 14 May 2014 01:27:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 20FEA642086; Wed, 14 May 2014 10:27:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCHp125OyuvG; Wed, 14 May 2014 10:27:32 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 93148642079 for ; Wed, 14 May 2014 10:27:32 +0200 (CEST) Message-ID: <537328F4.1080203@benocs.com> Date: Wed, 14 May 2014 10:27:32 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: idr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/7wI-l8W1s61Nqi6OJmbSwDFJBV4 Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 08:29:08 -0000 Hi guys, I support making this draft an RFC. However, I would like to see the following points addressed before that. 1. In section 4.2 there are some wrong attribute-names. MP_REACH should be MP_REACH_NLRI and MP_UNREACH should be MP_UNREACH_NLRI. 2. In section 6.4 there is also a wrong attribute-name. MULTI_EXIT_DESC should be MULTI_EXIT_DISC. 3. Is there a general approach (session-reset, treat-as-withdraw or attribute-discard) which should be taken if someone finds an error-situation which is neither covered by this document nor any other RFC? Section 7 mentions treat-as-withdraw as preferred approach. However, that section is "only" a guidance for authors of new BGP specifications. So maybe one should add the preferred approach in another section, e.g. in a section 2.1 ("General approach if nothing else applies"). 4. Section 3.d suggests to use the approach "treat-as-withdraw" if any of the well-known mandatory attributes are not present. Maybe one should add an extra note, that this does not apply for NEXT_HOP in the case of MP_REACH_NLRI being present in the UPDATE-message!? (I know, this is what RFC 4760 already says, but I think the current document would be more complete to include this note, too.) 5. (This point is probably very controversial.) If there is no known (up-to-date) implementation (or not even an old one) which violates the restrictions on MP_REACH_NLRI, MP_UNREACH_NLRI mentioned at the beginning of section 4, might it be possible to remove the following sentence which relaxes these restrictions again? (The sentence in question states: "In all these cases, however, an implementation MUST still be prepared to receive these fields in any position or combination.") 6. I remember to have read somewhere on the Internet or the IETF-mailing-list that it is current best practice to not send UPDATE-messages with both, non-empty Withdrawn Routes field and non-empty Network Layer Reachability Information field, in it (regardless of the presence of MP_(UN)REACH_NLRI). Maybe this information should also be included in the beginning of section 4, which then could become a subsection of its own. Thanks, Deniz Am 14.05.2014 02:27, schrieb John G. Scudder: > Folks, > > The version I've just posted incorporates most of the suggestions > received during the WGLC to date, including: > > - Added to the rationale given in the introduction. > - Refactored and cleaned up (the old) section 2 ("Revision to Base > Specification"). > - Further restrictions on where and how NLRI fields can be sent (in > summary, don't mix your encodings and don't mix MP_REACH and > MP_UNREACH). These are believed to follow current practice. > - Attribute length of zero generally disallowed, except in cases where > it actually makes sense (ATOMIC_AGGREGATE and sometimes AS_PATH). > - New "Guidance for Authors of BGP Specifications" section. > > And various other bits of polish. Rfcdiff is your friend. > > Thanks for all the review so far, it's been very productive. The main > open issue I'm currently aware of is Bruno's regarding whether we should > stop being draconian with MP_{UN}REACH flags. For my part, I take no > strong position on this and am happy to follow whatever the WG consensus is. > > --John > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Wed May 14 02:24:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEF01A0235; Wed, 14 May 2014 02:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNUMErAGYmwa; Wed, 14 May 2014 02:24:05 -0700 (PDT) Received: from out-5.mail.exa.net.uk (out-5.mail.exa.net.uk [82.219.4.133]) by ietfa.amsl.com (Postfix) with ESMTP id 709E21A0283; Wed, 14 May 2014 02:24:04 -0700 (PDT) Received: from smtp-1.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-5.mail.exa.net.uk (ExaSMTPD) with ESMTP id 5B0E21C024E; Wed, 14 May 2014 10:23:57 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-1.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id E131122115E; Wed, 14 May 2014 10:23:56 +0100 (BST) Content-Type: multipart/signed; boundary="Apple-Mail=_76A3FD9E-A531-4E13-A851-CDCD78D69CF5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Mangin In-Reply-To: Date: Wed, 14 May 2014 10:23:56 +0100 Cc: "idr@ietf. org" X-Mao-Original-Outgoing-Id: 421752236.303876-4ee1c435dcc34b1864ea77302fce7db3 Message-Id: References: To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.98.1 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/idr/1h5MetOhf69U-OI9ABEkfdrj1FU Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 09:24:07 -0000 --Apple-Mail=_76A3FD9E-A531-4E13-A851-CDCD78D69CF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello John, Sorry for the late comment, I am so late behind my mail. Could I just = ask you why the document recommend : o The MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL be encoded as the very first path attribute in an UPDATE. For the UN_UNREACH_NLRI, I have no question as AFAIU it does not matter = where it is. However to mirror the behaviour of RFC 4271 I would have expected to see = MP_REACH_NLRI as LAST attribute. ie: WITHDRAWN NLRI MP_UNREACH_NLRI MP_REACH_NLRI ANNOUNCED NLRI IPv4 only implementations are able to fully parse attributes and then be = able to associate them with the NLRI present at the end of the UPDATE. = Therefore I would have thought that to make it "simple" (yeah, right ! = :p), it would have been more logical to place MP_REACH_NLRI at the end = of the attribute set to mirror the non MP behaviour. I remember swearing to myself ( and cursing too most likely - please = excuse my french :p ) when I implemented MP support, as I could not = assume that MP_REACH_NLRI would be last. If I understand you correctly, you are saying that most major = implementations do not do this and place MP_REACH_NLRI first. I would be = curious to understand why and if the behaviour is indeed seen by every = implementation ? Even so, a SHALL can not help with any code = optimisation ( please tell me if you beg to differ ) therefore I fail to = understand why this was included (not that I am asking to the removal of = the text), I am barely trying to understand why it is here and if it is = the right thing to recommend. I wrote this paragraph before seeing the comment from Deniz. > (This point is probably very controversial.) > If there is no known (up-to-date) implementation (or not even an old = one)=20 > which violates the restrictions on MP_REACH_NLRI, MP_UNREACH_NLRI = mentioned at > the beginning of section 4, might it be possible to remove the = following > sentence which relaxes these restrictions again? > (The sentence in question states: "In all these cases, however, an=20 > implementation MUST still be prepared to receive these fields in any = position > or combination.") ExaBGP orders the attributes by increasing ID value as it is recommended = somewhere in 4271 I believe (I did not dig to find out if it is true) = and then append MP_UNREACH_NLRI and then MP_REACH_NLRI yield self._message(prefix(packed_del) + prefix(attr + packed_mp_del + = packed_mp_add) + packed_add) It is trivial to change but it does mean that at lease one = implementation do not follow this rule. >> There are any number of heuristics that may be applied to this >> problem. It would be helpful if, in practice, the vast majority of >> implementations only ever send one set of NLRI per message. It helps >> a bit if, in practice, MP_xx_REACH attributes only appear in messages >> where both the Withdraw Routes and NLRI parts are empty. Does = anybody >> know if either of these is the case ? > I (strongly) believe these to be common practice. I'm confident of it = for the > code base I've currently got access to, but can't speak = authoritatively for > others of course. Maybe other folks will chime in.=20 I know I never give this a thought. Chris, could you please elaborate on = why you seen this behaviour as advisable ? Thomas --Apple-Mail=_76A3FD9E-A531-4E13-A851-CDCD78D69CF5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlNzNiwACgkQA/52wvuLgaFlogCgwWyJ8wpLV/PTcC1FKGedtEkO 1PcAoJvzkFKxMNaLSIjf1wdHvpIowsNE =qfyC -----END PGP SIGNATURE----- --Apple-Mail=_76A3FD9E-A531-4E13-A851-CDCD78D69CF5-- From nobody Wed May 14 03:01:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA0E1A0291 for ; Wed, 14 May 2014 03:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jF1ioiv3SCu for ; Wed, 14 May 2014 03:01:11 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF241A0286 for ; Wed, 14 May 2014 03:01:11 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WkVzh-0007T0-Ok for idr@ietf.org; Wed, 14 May 2014 10:01:01 +0000 From: "Chris Hall" To: References: <537328F4.1080203@benocs.com> In-Reply-To: <537328F4.1080203@benocs.com> Date: Wed, 14 May 2014 11:00:56 +0100 Organization: Highwayman Message-ID: <05dd01cf6f5b$69588630$3c099290$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMPT2U8hNZfkQob/r9whEuUIHdu9wDftrY8mLkHkOA= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AwXIRbrkKcIAI2Nn2W8px-6Mlpk Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 10:01:13 -0000 Deniz Bahadir wrote (on Wed 14-May-2014 at 09:28 +0100): .... > 5. > (This point is probably very controversial.) > If there is no known (up-to-date) implementation (or not even > an old one) which violates the restrictions on MP_REACH_NLRI, > MP_UNREACH_NLRI mentioned at the beginning of section 4, might > it be possible to remove the following sentence which relaxes > these restrictions again? > (The sentence in question states: "In all these cases, however, an > implementation MUST still be prepared to receive these fields in any > position or combination.") I'm not sure this is true of the first restriction -- that MP_xx_NLRI must appear as the first attribute. But happily the second and third restrictions are sufficient to simplify the NLRI recovery problem. Assuming it is true, the most helpful thing that the draft could say is that: because there are (virtually) no known implementations which violate the second and third restrictions, the receiver MAY (well) choose to assume the sender conforms, whether or not it conforms to the rest of the draft/RFC. Having thus calmed the nerves of the paranoid (who can stop worrying about lost-NLRI as soon as they have one set in their hands), this leaves one case, where the receiver has found the message to be broken, would like to treat-as-withdraw, but has found no NLRI ! Presumably the receiver has no choice and must session-reset. This case is, of course, the rationale for the first restriction. Following the general impetus to not session-reset unless compelled to, I guess: a message which, putting to one side any MP_UNREACH_NLRI, contains a completely valid, but not empty, set of attributes, but no reachable NLRI should be treated-as-withdraw (of an empty set of NLRI, but logged as treat-as-withdraw). > 6. > I remember to have read somewhere on the Internet or the > IETF-mailing-list that it is current best practice to not > send UPDATE-messages with both, non-empty Withdrawn Routes > field and non-empty Network Layer Reachability Information > field, in it (regardless of the presence of MP_(UN)REACH_NLRI). > Maybe this information should also be included in the beginning of > section 4, which then could become a subsection of its own. It uses less pencil to specify that one UPDATE should contain just one set of NLRI, and is tidier :-) But, from the perspective of recovering the NLRI from a broken UPDATE message, the key is to limit the number of MP_xx_NLRI attributes. Chris From nobody Wed May 14 03:07:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EFA1A028B; Wed, 14 May 2014 03:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNCdHDlIpj5Q; Wed, 14 May 2014 03:07:29 -0700 (PDT) Received: from out-5.mail.exa.net.uk (out-5.mail.exa.net.uk [82.219.4.133]) by ietfa.amsl.com (Postfix) with ESMTP id C64EB1A027E; Wed, 14 May 2014 03:07:28 -0700 (PDT) Received: from smtp-2.mail.exa.net.uk (smtp-2.mail.exa.net.uk [82.219.5.2]) by out-5.mail.exa.net.uk (ExaSMTPD) with ESMTP id 136041C024E; Wed, 14 May 2014 11:07:21 +0100 (BST) Received: from ptr-34.212.219.82.rev.exa.net.uk (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id C6D0240281; Wed, 14 May 2014 11:07:20 +0100 (BST) Content-Type: multipart/signed; boundary="Apple-Mail=_7F279724-7830-4960-A921-04DB47810DE0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Mangin In-Reply-To: <05dd01cf6f5b$69588630$3c099290$@highwayman.com> Date: Wed, 14 May 2014 11:07:19 +0100 Cc: idr@ietf.org X-Mao-Original-Outgoing-Id: 421754839.032256-b815630992772984d432a2e5d82f87be Message-Id: References: <537328F4.1080203@benocs.com> <05dd01cf6f5b$69588630$3c099290$@highwayman.com> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.98.1 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/idr/BWfouNZPp6PUDrV7uO_6jRUcQt0 Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 10:07:30 -0000 --Apple-Mail=_7F279724-7830-4960-A921-04DB47810DE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 May 2014, at 11:00, Chris Hall wrote: > Assuming it is true, the most helpful thing that the draft could say > is that: because there are (virtually) no known implementations which > violate the second and third restrictions, the receiver MAY (well) > choose to assume the sender conforms, whether or not it conforms to > the rest of the draft/RFC. Sorry I realise my point about the order is invalid as ExaBGP does not = yet implement this draft. So all implementation may well have the MP first. Thomas --Apple-Mail=_7F279724-7830-4960-A921-04DB47810DE0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlNzQFcACgkQA/52wvuLgaG0MgCeK+L3NfgKs+6ZiXcywNHjUZKh HpwAoLvXR9xTILhgywZ9DsXi/9oFG15d =e+bW -----END PGP SIGNATURE----- --Apple-Mail=_7F279724-7830-4960-A921-04DB47810DE0-- From nobody Wed May 14 03:15:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4481A0011 for ; Wed, 14 May 2014 03:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnrrQAXdodBF for ; Wed, 14 May 2014 03:15:41 -0700 (PDT) Received: from mail.crfreenet.org (mail6.crfreenet.org [IPv6:2002:515c:9101:20::10]) by ietfa.amsl.com (Postfix) with ESMTP id A24831A001A for ; Wed, 14 May 2014 03:15:40 -0700 (PDT) Received: from localhost (ip-89-102-22-52.net.upcbroadband.cz [89.102.22.52]) by mail.crfreenet.org (Postfix) with ESMTP id D1978FCD6; Wed, 14 May 2014 12:15:32 +0200 (CEST) Received: from santiago by localhost with local (Exim 4.69) (envelope-from ) id 1WkWon-0007Kt-9q; Wed, 14 May 2014 12:53:49 +0200 Date: Wed, 14 May 2014 12:53:49 +0200 From: Ondrej Zajicek To: Deniz Bahadir Message-ID: <20140514105349.GB12659@localhost> References: <537328F4.1080203@benocs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <537328F4.1080203@benocs.com> X-Operating-System: Debian GNU/Linux User-Agent: Mutt/1.5.18 (2008-05-17) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/OIK3DAek2vlTFpwZH1LAIZ8LGBc Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 10:15:44 -0000 On Wed, May 14, 2014 at 10:27:32AM +0200, Deniz Bahadir wrote: > Hi guys, > > I support making this draft an RFC. > 4. > Section 3.d suggests to use the approach "treat-as-withdraw" if any of > the well-known mandatory attributes are not present. Maybe one should > add an extra note, that this does not apply for NEXT_HOP in the case of > MP_REACH_NLRI being present in the UPDATE-message!? > (I know, this is what RFC 4760 already says, but I think the current > document would be more complete to include this note, too.) > > 5. > (This point is probably very controversial.) > If there is no known (up-to-date) implementation (or not even an old > one) which violates the restrictions on MP_REACH_NLRI, MP_UNREACH_NLRI > mentioned at the beginning of section 4, might it be possible to remove > the following sentence which relaxes these restrictions again? > (The sentence in question states: "In all these cases, however, an > implementation MUST still be prepared to receive these fields in any > position or combination.") BIRD currently violates the first and the second restriction from section 4. It combines MP_REACH_NLRI and MP_UNREACH_NLRI in one update, sending MP_UNREACH_NLRI as first, then regular attributes, then MP_REACH_NLRI as last. > 6. > I remember to have read somewhere on the Internet or the > IETF-mailing-list that it is current best practice to not send > UPDATE-messages with both, non-empty Withdrawn Routes field and > non-empty Network Layer Reachability Information field, in it > (regardless of the presence of MP_(UN)REACH_NLRI). > Maybe this information should also be included in the beginning of > section 4, which then could become a subsection of its own. I agree. I suggest that the second and the third restriction from section 4 should be merged and extended to: An UPDATE message MUST NOT contain more than one of the following: non-empty Withdrawn Routes field, non-empty Network Layer Reachability Information field, MP_REACH_NLRI attribute, and MP_UNREACH_NLRI attribute. -- Ondrej 'Santiago' Zajicek From nobody Wed May 14 03:37:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FF21A002A for ; Wed, 14 May 2014 03:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUQcaET4Zroc for ; Wed, 14 May 2014 03:37:41 -0700 (PDT) Received: from mail.crfreenet.org (mail6.crfreenet.org [IPv6:2002:515c:9101:20::10]) by ietfa.amsl.com (Postfix) with ESMTP id 498781A0023 for ; Wed, 14 May 2014 03:37:41 -0700 (PDT) Received: from localhost (ip-89-102-22-52.net.upcbroadband.cz [89.102.22.52]) by mail.crfreenet.org (Postfix) with ESMTP id 69B77101D3; Wed, 14 May 2014 12:37:33 +0200 (CEST) Received: from santiago by localhost with local (Exim 4.69) (envelope-from ) id 1WkXA5-0007Xl-TS; Wed, 14 May 2014 13:15:49 +0200 Date: Wed, 14 May 2014 13:15:49 +0200 From: Ondrej Zajicek To: Thomas Mangin Message-ID: <20140514111549.GC12659@localhost> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux User-Agent: Mutt/1.5.18 (2008-05-17) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/OpnjoX2SaWiw3nbfCrnInFrn51I Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 10:37:44 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 14, 2014 at 10:23:56AM +0100, Thomas Mangin wrote: > Hello John, >=20 > Sorry for the late comment, I am so late behind my mail. Could I just ask= you why the document recommend : >=20 > o The MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL > be encoded as the very first path attribute in an UPDATE. >=20 > For the UN_UNREACH_NLRI, I have no question as AFAIU it does not matter w= here it is. AFAIU, MP_UNREACH_NLRI should be alone - if there are no 'positive' paths, then there is no point to add other attributes. > However to mirror the behaviour of RFC 4271 I would have expected to see = MP_REACH_NLRI as LAST attribute. ie: >=20 > WITHDRAWN NLRI > MP_UNREACH_NLRI > > MP_REACH_NLRI > ANNOUNCED NLRI >=20 > IPv4 only implementations are able to fully parse attributes and then > be able to associate them with the NLRI present at the end of the > UPDATE. Therefore I would have thought that to make it "simple" (yeah, > right ! :p), it would have been more logical to place MP_REACH_NLRI at > the end of the attribute set to mirror the non MP behaviour. Putting MP_REACH_NLRI last also makes sense from sender implementation point of view - you pack fixed number of your regular attributes first and then fill remaining available space by MP_REACH_NLRI (if you have too many paths with the same set of attributes), therefore i would also expect more implementations to send it last. --=20 Ondrej 'Santiago' Zajicek --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAlNzUGUACgkQw1GB2RHercNYTwCeLDSczhFLMlI+UBTbEoBw2MyR DYIAn1x+uw/gMV8ViR36IBTN63eXWhii =D9d1 -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From nobody Wed May 14 05:15:08 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8B81A0062 for ; Wed, 14 May 2014 05:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6k7N5BNzZ6D for ; Wed, 14 May 2014 05:15:05 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) by ietfa.amsl.com (Postfix) with ESMTP id 776071A002B for ; Wed, 14 May 2014 05:15:05 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WkY5J-0007UE-QN for idr@ietf.org; Wed, 14 May 2014 12:14:57 +0000 From: "Chris Hall" To: "'idr@ietf. org'" References: In-Reply-To: Date: Wed, 14 May 2014 13:14:52 +0100 Organization: Highwayman Message-ID: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMPT2U8hNZfkQob/r9whEuUIHdu9wIXLiUimK9emEA= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/4RCACqPEKpnOX5fdsZ3AjwEoDA4 Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 12:15:07 -0000 Thomas Mangin wrote (on Wed 14-May-2014 at 10:24 +0100): .... > >> There are any number of heuristics that may be applied to > >> this problem. It would be helpful if, in practice, the vast > >> majority of implementations only ever send one set of NLRI > >> per message. It helps a bit if, in practice, MP_xx_REACH > >> attributes only appear in messages where both the Withdraw > >> Routes and NLRI parts are empty. Does anybody know if > >> either of these is the case ? > > I (strongly) believe these to be common practice. I'm > > confident of it for the code base I've currently got access > > to, but can't speak authoritatively for others of course. > > Maybe other folks will chime in. > I know I never give this a thought. Chris, could you please > elaborate on why you seen this behaviour as advisable ? OK... you asked, so here goes... ...in the following: "MP_xx_NLRI" means one or both of MP_REACH_NLRI and MP_UNREACH_NLRI attributes; Body-NLRI refers to one or both of the Withdrawn Routes and NLRI sections of the UPDATE message -- the NLRI outside the attributes; a "set of NLRI" refers to any one of the MP_xx_NLRI and Body-NLRI; and "NLRI" refers to any or all sets of NLRI in an UPDATE message. ...and this is my understanding of the problem... ...(1) for treat-as-withdraw to be "safe" (or as safe as possible) it is essential that *all* NLRI in a broken update can be recovered. For if not, then treat-as-withdraw is "incomplete", and leaves the receiver with out-of-date routes in its hands, whose value is (to say the least) indeterminate. ...(2) the standard(s) allow for an UPDATE to contain between 1 and 4 sets of NLRI. ...(3) depending on how broken the message is, there may be 0, 1 or 2 MP_xx_NLRI attributes buried somewhere in the rubble, and the receiver cannot tell how much has been lost -- the lost-NLRI. If there are no Body-NLRI, then the receiver may assume that there are 1 or 2 lost-NLRI. ...(4) if the sender follows the MP_xx_NLRI first rule, they sit on top of the rubble and can be recovered. This is a change in the standard which one hopes will be implemented and deployed in some time. But in any case, the receiver has no way of telling whether the sender intends to follow the rule (or has succeeded !). So, if the receiver does not find MP_xx_NLRI, it may have to assume the worst. ...(5) if lost-NLRI are a problem, or a problem worse than session-reset, then the receiver appears to be in the unenviable position of having to balance the risk/cost of an "incomplete" treat-as-withdraw against the benefit of avoiding (the dreaded) session-reset. ...(6) if some/many/most/all lost-NLRI are worse than session-reset, then when can treat-as-withdraw be used ? At this point I go and hide under my desk. But, if in practice an UPDATE only ever contains 1 set of NLRI, then my descent into a paranoid, quivering wreck stops at step 2. Hurrah ! This is slightly stricter than it needs to be: there is no problem with both sets of body-NLRI appearing together. Now, you can argue that the only thing a receiver *can* do is to treat-as-withdraw on the basis of the NLRI it can see, and not worry about things it cannot see -- so that's what it *ought* to do. As a practical matter, errors are rare... errors which result in lost-NLRI are rarer still... the result is probably not as bad as session-reset... and the operator should be got out of bed to deal with the root-cause pretty sharpish, so any bad effects will be temporary... and in any case treat-as-withdraw is not a perfect work-around, just the best we have. Trying to decide when it is more or less likely that there are lost-NLRI -- searching through the rubble for possible survivors -- looks like a tricky problem, and best avoided. If, de facto, the receiver can assume that messages contain either body-NLRI or just one MP_xx_NLRI attribute, then what the receiver *can* do doesn't change, but what it *ought* to do is less problematic, and the rationale requires much, much less hand waving. It's not necessary for absolutely every sender to be absolutely guaranteed to follow this (post hoc) rule. For the minority that don't work this way, the hand waving argument may be deployed. But the smaller that minority is, the less vigorous the hand waving has to be to make the point. For completeness, note that the MP_xx_NLRI at the front rule is orthogonal to this. Senders which follow the rule are less likely to generate a broken UPDATE from which the NLRI cannot be recovered. The rule is not relevant to what the receiver does with the UPDATE. Chris From nobody Wed May 14 06:21:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDAF1A02CA for ; Wed, 14 May 2014 06:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl72Obiv3glS for ; Wed, 14 May 2014 06:21:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 202E71A02C6 for ; Wed, 14 May 2014 06:21:35 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 95EB422C3A2 for ; Wed, 14 May 2014 15:21:28 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7E7734C169 for ; Wed, 14 May 2014 15:21:28 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 14 May 2014 15:21:28 +0200 From: To: "'idr@ietf. org'" Thread-Topic: [Idr] draft-ietf-idr-error-handling-08 Thread-Index: AQMPT2U8hNZfkQob/r9whEuUIHdu9wIXLiUimK9emECAADT2oA== Date: Wed, 14 May 2014 13:21:28 +0000 Message-ID: <8811_1400073688_53736DD8_8811_17005_1_53C29892C857584299CBF5D05346208A07149FAC@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> In-Reply-To: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.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.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.13.75120 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ruiNkk2c9vy6GWMexZnLuCHCuO8 Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 13:21:42 -0000 Hi all, > ...(5) if lost-NLRI are a problem, or a problem worse than session-reset,= then the receiver appears to be in the unenviable position of having to ba= lance the risk/cost of an "incomplete" treat-as-withdraw against the benefit of avoiding (the dreaded) session-res= et. IINM, we have a new tool to protect/insure against the risk of an incomplet= e treat-as-withdraw (aka missing NLRI in an erroneous update): http://tools= .ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-06 Possibly, draft-ietf-idr-error-handling could add a note about this recover= y option. (if so, I would propose to (randomly) delay the sending of the Ro= ute Refresh message since the BGP speaker (our BGP peer) is possibly busy h= andling BGP NOTIFICATIONs from others peers) Regards, Bruno PS: Looks somewhat ironic (to me) that this tool has been defined to recove= r missing NLRI from well-formed BGP UPDATE, and not from erroneous ones ;-) > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Chris Hall > Sent: Wednesday, May 14, 2014 2:15 PM > To: 'idr@ietf. org' > Subject: Re: [Idr] draft-ietf-idr-error-handling-08 >=20 > Thomas Mangin wrote (on Wed 14-May-2014 at 10:24 +0100): > .... > > >> There are any number of heuristics that may be applied to this > > >> problem. It would be helpful if, in practice, the vast majority of > > >> implementations only ever send one set of NLRI per message. It > > >> helps a bit if, in practice, MP_xx_REACH attributes only appear in > > >> messages where both the Withdraw Routes and NLRI parts are empty. > > >> Does anybody know if either of these is the case ? >=20 > > > I (strongly) believe these to be common practice. I'm confident of > > > it for the code base I've currently got access to, but can't speak > > > authoritatively for others of course. > > > Maybe other folks will chime in. >=20 > > I know I never give this a thought. Chris, could you please elaborate > > on why you seen this behaviour as advisable ? >=20 > OK... you asked, so here goes... >=20 > ...in the following: "MP_xx_NLRI" means one or both of MP_REACH_NLRI > and MP_UNREACH_NLRI attributes; Body-NLRI refers to one or both of the > Withdrawn Routes and NLRI sections of the UPDATE message -- the NLRI > outside the attributes; a "set of NLRI" refers to any one of the MP_xx_NL= RI > and Body-NLRI; and "NLRI" refers to any or all sets of NLRI in an UPDATE > message. >=20 > ...and this is my understanding of the problem... >=20 > ...(1) for treat-as-withdraw to be "safe" (or as safe as possible) it is = essential > that *all* NLRI in a broken update can be recovered. For if not, then tr= eat- > as-withdraw is "incomplete", and leaves the receiver with out-of-date rou= tes > in its hands, whose value is (to say the least) indeterminate. >=20 > ...(2) the standard(s) allow for an UPDATE to contain between 1 and 4 set= s of > NLRI. >=20 > ...(3) depending on how broken the message is, there may be 0, 1 or 2 > MP_xx_NLRI attributes buried somewhere in the rubble, and the receiver > cannot tell how much has been lost -- the lost-NLRI. If there are no Bod= y- > NLRI, then the receiver may assume that there are 1 or 2 lost-NLRI. >=20 > ...(4) if the sender follows the MP_xx_NLRI first rule, they sit on top o= f the > rubble and can be recovered. This is a change in the standard which one > hopes will be implemented and deployed in some time. But in any case, the > receiver has no way of telling whether the sender intends to follow the r= ule > (or has succeeded !). So, if the receiver does not find MP_xx_NLRI, it m= ay > have to assume the worst. >=20 > ...(5) if lost-NLRI are a problem, or a problem worse than session-reset,= then > the receiver appears to be in the unenviable position of having to balance > the risk/cost of an "incomplete" > treat-as-withdraw against the benefit of avoiding (the dreaded) session- > reset. >=20 > ...(6) if some/many/most/all lost-NLRI are worse than session-reset, then > when can treat-as-withdraw be used ? >=20 > At this point I go and hide under my desk. >=20 > But, if in practice an UPDATE only ever contains 1 set of NLRI, then my > descent into a paranoid, quivering wreck stops at step 2. Hurrah ! >=20 > This is slightly stricter than it needs to be: there is no problem with b= oth sets > of body-NLRI appearing together. >=20 > Now, you can argue that the only thing a receiver *can* do is to treat-as- > withdraw on the basis of the NLRI it can see, and not worry about things = it > cannot see -- so that's what it *ought* to do. As a practical matter, er= rors are > rare... errors which result in lost-NLRI are rarer still... the result is= probably > not as bad as session-reset... and the operator should be got out of bed = to > deal with the root-cause pretty sharpish, so any bad effects will be > temporary... and in any case treat-as-withdraw is not a perfect work-arou= nd, > just the best we have. Trying to decide when it is more or less likely t= hat > there are lost-NLRI -- searching through the rubble for possible survivor= s -- > looks like a tricky problem, and best avoided. >=20 > If, de facto, the receiver can assume that messages contain either body-N= LRI > or just one MP_xx_NLRI attribute, then what the receiver > *can* do doesn't change, but what it *ought* to do is less problematic, a= nd > the rationale requires much, much less hand waving. >=20 > It's not necessary for absolutely every sender to be absolutely guarantee= d to > follow this (post hoc) rule. For the minority that don't work this way, = the > hand waving argument may be deployed. But the smaller that minority is, > the less vigorous the hand waving has to be to make the point. >=20 > For completeness, note that the MP_xx_NLRI at the front rule is orthogonal > to this. Senders which follow the rule are less likely to generate a bro= ken > UPDATE from which the NLRI cannot be recovered. The rule is not relevant > to what the receiver does with the UPDATE. >=20 > Chris >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed May 14 06:31:58 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890911A008A for ; Wed, 14 May 2014 06:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D9hjG8epqHb for ; Wed, 14 May 2014 06:31:55 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) by ietfa.amsl.com (Postfix) with ESMTP id 36D331A0066 for ; Wed, 14 May 2014 06:31:55 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WkZHf-0007VG-QG for idr@ietf.org; Wed, 14 May 2014 13:31:47 +0000 From: "Chris Hall" To: References: <537328F4.1080203@benocs.com> <20140514105349.GB12659@localhost> In-Reply-To: <20140514105349.GB12659@localhost> Date: Wed, 14 May 2014 14:31:41 +0100 Organization: Highwayman Message-ID: <060c01cf6f78$da980bf0$8fc823d0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMPT2U8hNZfkQob/r9whEuUIHdu9wDftrY8AdnU+yyYqnPkkA== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NfT0dC72dWBZ5YGwyTRQBJGYF0g Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 13:31:57 -0000 Ondrej Zajicek wrote (on Wed 14-May-2014 11:54 at +0100): ... > BIRD currently violates the first and the second restriction from > section 4. It combines MP_REACH_NLRI and MP_UNREACH_NLRI in one > update, sending MP_UNREACH_NLRI as first, then regular attributes, > then MP_REACH_NLRI as last. Current versions of Quagga also send MP_UNREACH_NLRI as the last attribute. But it only sends one set of NLRI per message. >From the point of view of the receiver, the second restriction can be loosened a little, so that it may assume any MP_UNREACH_NLRI will be the first or only attribute. Hence, if the attributes are broken in any way: (a) if the first attribute is not MP_UNREACH_NLRI, then the receiver assumes there are no MP_UNREACH_NLRI, and (b) if there are any other attributes, then there must be an MP_REACH_NLRI somewhere. The draft can specify that, in future, the sender MUST send just one set of NLRI and MUST send any MP_xx_NLRI as the first attribute. And when senders do that, things are simpler and NLRI less likely to be lost. >From the receiver's perspective, what matters is the assumptions it may reasonably make when deciding whether it can "safely" do treat-as-withdraw. In the short run it cannot assume the sender is following the new rules. But it looks as if, de facto, there are simplifying assumptions the receiver can make, now -- whether or not the sender is following the new rules. IMO the draft is the place to document those de facto assumptions. Chris From nobody Wed May 14 09:00:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0485C1A00B8 for ; Wed, 14 May 2014 08:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwXnIOr4dRzG for ; Wed, 14 May 2014 08:49:34 -0700 (PDT) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBC71A00A6 for ; Wed, 14 May 2014 08:49:34 -0700 (PDT) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s4EFnFYB021928; Wed, 14 May 2014 11:49:15 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201405141549.s4EFnFYB021928@maildrop2.v6ds.occnc.com> To: "John G. Scudder" From: Curtis Villamizar In-reply-to: Your message of "Wed, 07 May 2014 11:12:01 -0400." <7176992A-CE2F-45E1-8C27-E61465E55A50@juniper.net> Date: Wed, 14 May 2014 11:49:15 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/UpyiJ8GZFsn-mcZwfHo0NBcz2_Q X-Mailman-Approved-At: Wed, 14 May 2014 09:00:26 -0700 Cc: "idr@ietf. org" , guban@microsoft.com, govindan@isi.edu, Ravi Chandra , Hares Susan , RFC Errata System Subject: Re: [Idr] [Technical Errata Reported] RFC2439 (3964) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:49:37 -0000 John, Gunjan, John is correct on both points. The document lacks clarity in general, and the reuse list is used for both reachable and unreachable routes, disposing of all history associated with the route if it unreachable. Two structures could have been used but it is computationally more efficient to have one slightly more dense data structure than two slightly more sparse data structures. Except for the sentence that John pointed to the document is not clear about this. A rewrite of RFC2439 is long overdue but would risk reigniting old flame wars. If the rewrite was clear about deployment experience section were clear about the problems that have occurred, then the flame wars might not be so intense. Curtis In message <7176992A-CE2F-45E1-8C27-E61465E55A50@juniper.net> "John G. Scudder" writes: > > Hi Gunjan, > > RFC 2439 isn't the easiest to read, but according to my reading this erratum is not correct. Despite its name, the "reuse list" as described in S. 4.8.7 is used for processing timer-driven events in general, including freeing up damping structures ("histories"). Quoting from S. 4.8.7, "Handling Reuse Timer Events": > > all of the routes in the first queue will be > available for immediate reuse if reachable or the history entry could > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > be disposed of if unreachable. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > If you have any doubt that "history" means "damping structure", take a look at S. 4.8.2: > > If there is no previous stability history (the damping structure > pointer is zero), then: > > I assume you're clear on why histories for unreachable routes need to be maintained to begin with. > > I'm going to recommend to the AD that this erratum be rejected, unless you or someone else wants to make a case why it shouldn't be. > > Thanks, > > --John > > On Apr 15, 2014, at 10:36 AM, RFC Errata System wrote: > > > The following errata report has been submitted for RFC2439, > > "BGP Route Flap Damping". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=2439&eid=3964 > > > > -------------------------------------- > > Type: Technical > > Reported by: Gunjan Bansal > > > > Section: 4.8.2 > > > > Original Text > > ------------- > > In either case then: > > > > 1. set t-updated = t-now > > > > 2. insert into a reuse list (see Section 4.8.6) > > > > Corrected Text > > -------------- > > In either case then: > > > > 1. set t-updated = t-now > > > > > > Notes > > ----- > > The route which is unreachable should NOT be inserted into the reuse-list. reuse-list (as per explanation in Section 4.8.7) is used for fast evaluation of routes which have been suppressed long enough and can be potentially used again. The "unreachability/withdrawal" of route is never suppressed and never needs to be re-evaluated in future. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC2439 (no draft string recorded) > > -------------------------------------- > > Title : BGP Route Flap Damping > > Publication Date : November 1998 > > Author(s) : C. Villamizar, R. Chandra, R. Govindan > > Category : PROPOSED STANDARD > > Source : Inter-Domain Routing > > Area : Routing > > Stream : IETF > > Verifying Party : IESG From nobody Wed May 14 09:24:54 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E3B1A02ED for ; Wed, 14 May 2014 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLVACCl7RSfC for ; Wed, 14 May 2014 09:24:50 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 609231A02C6 for ; Wed, 14 May 2014 09:24:47 -0700 (PDT) X-AuditID: c6180641-f799b6d000000b0f-e4-537346f89e30 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D6.90.02831.9F643735; Wed, 14 May 2014 12:35:37 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Wed, 14 May 2014 12:24:39 -0400 From: Jakob Heitz To: Chris Hall Thread-Topic: [Idr] draft-ietf-idr-error-handling-08 Thread-Index: AQHPbwtniCs8s7yj9Ua/wHoOdLCWfZtAEWwAgAAvwgCAAAK9vg== Date: Wed, 14 May 2014 16:24:39 +0000 Message-ID: <11670625-A436-4EA4-B1BD-A5778028A409@ericsson.com> References: , <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> In-Reply-To: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXRPrO5Pt+Jggz/nRSze/9rGbPHq9jMm ByaP40d3MXssWfKTKYApissmJTUnsyy1SN8ugStjzZF/LAXPNSuWN+g1MC5X7GLk5JAQMJFo aXzIDGGLSVy4t56ti5GLQ0jgKKPEiYc3WCGc5YwS22Y3MoJUsQnoSHy73gXWISKgJbF6wyw2 EJtZQEli29SD7CC2sICxxOwZF6BqTCQ29j5hh7CdJCZO+ws0lIODRUBVouNXHkiYV8Beovt2 AzPErtWMEpP+PwebySlgKzF5/WtWEJsR6Lrvp9YwQewSl7j1ZD4TxNUCEkv2nIf6QFTi5eN/ rBA1OhILdn+Cuk1bYtnC18wQywQlTs58wjKBUXQWklGzkLTMQtIyC0nLAkaWVYwcpcWpZbnp RoabGIHRcEyCzXEH44JPlocYBTgYlXh4E1WLgoVYE8uKK3MPMUpzsCiJ86Z/ig0WEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwDjFL19ON8Qt6GSM/qOe2T/Pvv4xJ1s8PvM7z03/pcyPX90Q P1Pl2BxgHrm9hDu7bN4RYa3Nrj7vODl3fmfnD+bZfkl5x16uGcsSDl5ZIb1T6Omh4KdyBpFP +KVnHeQ4v1r84b4tjPICx+ebLgm9HCPtdPyL+KqwWTI/C8RNPZo9Xad9fTHpaKYSS3FGoqEW c1FxIgBXmOUQZwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/idr/4GQVv9rL_cXaWbOUkl4AfmJJYO8 Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:24:52 -0000 A receiver can not assume that there will only ever be one "set of NLRI" an= d that it will appear first (unless it is the NLRI section), unless we add = a capability. -- Jakob Heitz. > On May 14, 2014, at 5:15 AM, "Chris Hall" wro= te: >=20 > Thomas Mangin wrote (on Wed 14-May-2014 at 10:24 +0100): > .... >>>> There are any number of heuristics that may be applied to=20 >>>> this problem. It would be helpful if, in practice, the vast >>>> majority of implementations only ever send one set of NLRI >>>> per message. It helps a bit if, in practice, MP_xx_REACH >>>> attributes only appear in messages where both the Withdraw >>>> Routes and NLRI parts are empty. Does anybody know if >>>> either of these is the case ? >=20 >>> I (strongly) believe these to be common practice. I'm=20 >>> confident of it for the code base I've currently got access >>> to, but can't speak authoritatively for others of course. >>> Maybe other folks will chime in. >=20 >> I know I never give this a thought. Chris, could you please >> elaborate on why you seen this behaviour as advisable ? >=20 > OK... you asked, so here goes... >=20 > ...in the following: "MP_xx_NLRI" means one or both of MP_REACH_NLRI > and MP_UNREACH_NLRI attributes; Body-NLRI refers to one or both of the > Withdrawn Routes and NLRI sections of the UPDATE message -- the NLRI > outside the attributes; a "set of NLRI" refers to any one of the > MP_xx_NLRI and Body-NLRI; and "NLRI" refers to any or all sets of NLRI > in an UPDATE message. >=20 > ...and this is my understanding of the problem... >=20 > ...(1) for treat-as-withdraw to be "safe" (or as safe as possible) it > is essential that *all* NLRI in a broken update can be recovered. For > if not, then treat-as-withdraw is "incomplete", and leaves the > receiver with out-of-date routes in its hands, whose value is (to say > the least) indeterminate. >=20 > ...(2) the standard(s) allow for an UPDATE to contain between 1 and 4 > sets of NLRI. >=20 > ...(3) depending on how broken the message is, there may be 0, 1 or 2 > MP_xx_NLRI attributes buried somewhere in the rubble, and the receiver > cannot tell how much has been lost -- the lost-NLRI. If there are no > Body-NLRI, then the receiver may assume that there are 1 or 2 > lost-NLRI. >=20 > ...(4) if the sender follows the MP_xx_NLRI first rule, they sit on > top of the rubble and can be recovered. This is a change in the > standard which one hopes will be implemented and deployed in some > time. But in any case, the receiver has no way of telling whether the > sender intends to follow the rule (or has succeeded !). So, if the > receiver does not find MP_xx_NLRI, it may have to assume the worst. >=20 > ...(5) if lost-NLRI are a problem, or a problem worse than > session-reset, then the receiver appears to be in the unenviable > position of having to balance the risk/cost of an "incomplete" > treat-as-withdraw against the benefit of avoiding (the dreaded) > session-reset. >=20 > ...(6) if some/many/most/all lost-NLRI are worse than session-reset, > then when can treat-as-withdraw be used ? >=20 > At this point I go and hide under my desk. >=20 > But, if in practice an UPDATE only ever contains 1 set of NLRI, then > my descent into a paranoid, quivering wreck stops at step 2. Hurrah ! >=20 > This is slightly stricter than it needs to be: there is no problem > with both sets of body-NLRI appearing together. >=20 > Now, you can argue that the only thing a receiver *can* do is to > treat-as-withdraw on the basis of the NLRI it can see, and not worry > about things it cannot see -- so that's what it *ought* to do. As a > practical matter, errors are rare... errors which result in lost-NLRI > are rarer still... the result is probably not as bad as > session-reset... and the operator should be got out of bed to deal > with the root-cause pretty sharpish, so any bad effects will be > temporary... and in any case treat-as-withdraw is not a perfect > work-around, just the best we have. Trying to decide when it is more > or less likely that there are lost-NLRI -- searching through the > rubble for possible survivors -- looks like a tricky problem, and best > avoided. >=20 > If, de facto, the receiver can assume that messages contain either > body-NLRI or just one MP_xx_NLRI attribute, then what the receiver > *can* do doesn't change, but what it *ought* to do is less > problematic, and the rationale requires much, much less hand waving. >=20 > It's not necessary for absolutely every sender to be absolutely > guaranteed to follow this (post hoc) rule. For the minority that > don't work this way, the hand waving argument may be deployed. But > the smaller that minority is, the less vigorous the hand waving has to > be to make the point. >=20 > For completeness, note that the MP_xx_NLRI at the front rule is > orthogonal to this. Senders which follow the rule are less likely to > generate a broken UPDATE from which the NLRI cannot be recovered. The > rule is not relevant to what the receiver does with the UPDATE. >=20 > Chris >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 14 10:14:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E261A029F for ; Wed, 14 May 2014 10:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSxdD9Qd71qn for ; Wed, 14 May 2014 10:14:18 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) by ietfa.amsl.com (Postfix) with ESMTP id EDB701A00B2 for ; Wed, 14 May 2014 10:14:17 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 9so1823981ykp.13 for ; Wed, 14 May 2014 10:14:11 -0700 (PDT) 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:content-transfer-encoding; bh=da0+nRFQ5Pbeey0cpe6XGs52EHsKTy/RjjN0XS+L/b4=; b=enlsjCnvLLZQBRCNs0DEmS2yqDl9NVcWy9gdsu2ZbDqyVE1+c31PDDLs3e0xK6ZOym yPcE78hPXO6gGCLfADzxSPTNs3z0RWnHerfc0rpMauRgV3cUg+1ghPAk3RHS9adcznMd gPNJWNvNkvxxuLD6hJljiLpzHeqrRVEr5J8jeII5E1u4WFV6Br/Z8LNLD+3XYY9bWz7n leKc9zYl/5sJr4/3Uv+gu+51qvbQRo+3nAZvn0GbwYne8zwVSU4wHxm0Ioeho8rOgYHC gxRYld83Mbl/qDcb5oho5SoDgFfrMEshItJTw+PwjFx9+VnHgzlaDtB5FmAGpBBvt2MW 0QxQ== MIME-Version: 1.0 X-Received: by 10.236.220.72 with SMTP id n68mr7274249yhp.102.1400087651196; Wed, 14 May 2014 10:14:11 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Wed, 14 May 2014 10:14:11 -0700 (PDT) In-Reply-To: <201405141549.s4EFnFYB021928@maildrop2.v6ds.occnc.com> References: <7176992A-CE2F-45E1-8C27-E61465E55A50@juniper.net> <201405141549.s4EFnFYB021928@maildrop2.v6ds.occnc.com> Date: Wed, 14 May 2014 13:14:11 -0400 Message-ID: From: Alia Atlas To: "curtis@ipv6.occnc.com" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ljR-WQ0OYigzObdDjl0pFNyoKOU Cc: "idr@ietf. org" , guban@microsoft.com, govindan@isi.edu, Ravi Chandra , Hares Susan , RFC Errata System Subject: Re: [Idr] [Technical Errata Reported] RFC2439 (3964) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:14:20 -0000 It is excellent to push well implemented and understood RFCs to a Full Stan= dard. Alia On Wed, May 14, 2014 at 11:49 AM, Curtis Villamizar wrote: > > John, Gunjan, > > John is correct on both points. The document lacks clarity in > general, and the reuse list is used for both reachable and unreachable > routes, disposing of all history associated with the route if it > unreachable. > > Two structures could have been used but it is computationally more > efficient to have one slightly more dense data structure than two > slightly more sparse data structures. Except for the sentence that > John pointed to the document is not clear about this. > > A rewrite of RFC2439 is long overdue but would risk reigniting old > flame wars. If the rewrite was clear about deployment experience > section were clear about the problems that have occurred, then the > flame wars might not be so intense. > > Curtis > > > In message <7176992A-CE2F-45E1-8C27-E61465E55A50@juniper.net> > "John G. Scudder" writes: >> >> Hi Gunjan, >> >> RFC 2439 isn't the easiest to read, but according to my reading this err= atum is not correct. Despite its name, the "reuse list" as described in S. = 4.8.7 is used for processing timer-driven events in general, including free= ing up damping structures ("histories"). Quoting from S. 4.8.7, "Handling R= euse Timer Events": >> >> all of the routes in the first queue will be >> available for immediate reuse if reachable or the history entry could >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> be disposed of if unreachable. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> If you have any doubt that "history" means "damping structure", take a l= ook at S. 4.8.2: >> >> If there is no previous stability history (the damping structure >> pointer is zero), then: >> >> I assume you're clear on why histories for unreachable routes need to be= maintained to begin with. >> >> I'm going to recommend to the AD that this erratum be rejected, unless y= ou or someone else wants to make a case why it shouldn't be. >> >> Thanks, >> >> --John >> >> On Apr 15, 2014, at 10:36 AM, RFC Errata System wrote: >> >> > The following errata report has been submitted for RFC2439, >> > "BGP Route Flap Damping". >> > >> > -------------------------------------- >> > You may review the report below and at: >> > http://www.rfc-editor.org/errata_search.php?rfc=3D2439&eid=3D3964 >> > >> > -------------------------------------- >> > Type: Technical >> > Reported by: Gunjan Bansal >> > >> > Section: 4.8.2 >> > >> > Original Text >> > ------------- >> > In either case then: >> > >> > 1. set t-updated =3D t-now >> > >> > 2. insert into a reuse list (see Section 4.8.6) >> > >> > Corrected Text >> > -------------- >> > In either case then: >> > >> > 1. set t-updated =3D t-now >> > >> > >> > Notes >> > ----- >> > The route which is unreachable should NOT be inserted into the reuse-l= ist. reuse-list (as per explanation in Section 4.8.7) is used for fast eval= uation of routes which have been suppressed long enough and can be potentia= lly used again. The "unreachability/withdrawal" of route is never suppresse= d and never needs to be re-evaluated in future. >> > >> > Instructions: >> > ------------- >> > This errata is currently posted as "Reported". If necessary, please >> > use "Reply All" to discuss whether it should be verified or >> > rejected. When a decision is reached, the verifying party (IESG) >> > can log in to change the status and edit the report, if necessary. >> > >> > -------------------------------------- >> > RFC2439 (no draft string recorded) >> > -------------------------------------- >> > Title : BGP Route Flap Damping >> > Publication Date : November 1998 >> > Author(s) : C. Villamizar, R. Chandra, R. Govindan >> > Category : PROPOSED STANDARD >> > Source : Inter-Domain Routing >> > Area : Routing >> > Stream : IETF >> > Verifying Party : IESG > From nobody Wed May 14 12:21:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA8F1A01D7 for ; Wed, 14 May 2014 12:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYT91RjFgKJm for ; Wed, 14 May 2014 12:21:06 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) by ietfa.amsl.com (Postfix) with ESMTP id 53DE41A0157 for ; Wed, 14 May 2014 12:21:01 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WkejS-0007a2-Ux for idr@ietf.org; Wed, 14 May 2014 19:20:51 +0000 From: "Chris Hall" To: "'idr@ietf. org'" References: , <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <11670625-A436-4EA4-B1BD-A5778028A409@ericsson.com> In-Reply-To: <11670625-A436-4EA4-B1BD-A5778028A409@ericsson.com> Date: Wed, 14 May 2014 20:20:45 +0100 Organization: Highwayman Message-ID: <066801cf6fa9$9e1ed290$da5c77b0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMPT2U8hNZfkQob/r9whEuUIHdu9wIXLiUiAce54KwCTGwpz5iPNc+g Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/UpWuuaAwE5QtdiIUhou4QVC_gHg Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 19:21:09 -0000 Jakob Heitz wrote (on Wed 14-May-2014 at 17:25 +0100): > > A receiver can not assume that there will only ever be one "set of > NLRI" and that it will appear first (unless it is the NLRI section), > unless we add a capability. I think that perhaps we are using "assume" to mean slightly different things here. In the absence of a capability, the sender is entitled to follow existing standards, and the receiver is required to cope. On receipt of such a capability the receiver would be entitled to expect the new behaviour. That much I think is uncontroversial. However, the object of the whole exercise is to handle errors more gracefully, so whatever the receiver feels entitled to expect is largely moot. When trying to cope with broken attributes the receiver cannot *know* what was intended and at some point has to *assume* something. This is in this sense of "assume" I have in mind. The choice of assumptions that the receiver can make is a large part of the draft, and each assumption is designed to balance simplicity, routeing safety and a desire to avoid the (dreaded) session-reset. For example, the current draft says that: faced with what appears to be a LOCAL_PREF attribute of length 2000, the receiver MUST assume that this is indeed an oversize LOCAL_PREF attribute -- although it could be that the previous attribute was, in fact, broken and the receiver is currently attempting to parse complete nonsense. It appears that many/most/nearly-all BGP implementations only do a subset of the things allowed by the current (de jure) standard. From what I've heard recently, in current implementations: * MP_xx_NLRI and Body-NLRI do not appear together in an UPDATE message. * MP_UNREACH_NLRI is always the first (or only) attribute. Happily, the proposed de jure standard in the current draft is compatible with this, but a smidge more restrictive. If this de facto "standard" turns out to be followed by sufficient implementations, then for the purposes of dealing with broken attributes, and in the absence of anything else to go on, I suggest the receiver not only can, but should, assume these things. Chris > > On May 14, 2014, at 5:15 AM, "Chris Hall" > wrote: > > > > Thomas Mangin wrote (on Wed 14-May-2014 at 10:24 +0100): > > .... > >>>> There are any number of heuristics that may be applied to > >>>> this problem. It would be helpful if, in practice, the vast > >>>> majority of implementations only ever send one set of NLRI > >>>> per message. It helps a bit if, in practice, MP_xx_REACH > >>>> attributes only appear in messages where both the Withdraw > >>>> Routes and NLRI parts are empty. Does anybody know if > >>>> either of these is the case ? > > > >>> I (strongly) believe these to be common practice. I'm > >>> confident of it for the code base I've currently got access > >>> to, but can't speak authoritatively for others of course. > >>> Maybe other folks will chime in. > > > >> I know I never give this a thought. Chris, could you please > >> elaborate on why you seen this behaviour as advisable ? > > > > OK... you asked, so here goes... > > > > ...in the following: "MP_xx_NLRI" means one or both of > MP_REACH_NLRI > > and MP_UNREACH_NLRI attributes; Body-NLRI refers to one or both of > the > > Withdrawn Routes and NLRI sections of the UPDATE message -- the > NLRI > > outside the attributes; a "set of NLRI" refers to any one of the > > MP_xx_NLRI and Body-NLRI; and "NLRI" refers to any or all sets of > NLRI > > in an UPDATE message. > > > > ...and this is my understanding of the problem... > > > > ...(1) for treat-as-withdraw to be "safe" (or as safe as possible) > it > > is essential that *all* NLRI in a broken update can be recovered. > For > > if not, then treat-as-withdraw is "incomplete", and leaves the > > receiver with out-of-date routes in its hands, whose value is (to > say > > the least) indeterminate. > > > > ...(2) the standard(s) allow for an UPDATE to contain between 1 > and 4 > > sets of NLRI. > > > > ...(3) depending on how broken the message is, there may be 0, 1 > or 2 > > MP_xx_NLRI attributes buried somewhere in the rubble, and the > receiver > > cannot tell how much has been lost -- the lost-NLRI. If there are > no > > Body-NLRI, then the receiver may assume that there are 1 or 2 > > lost-NLRI. > > > > ...(4) if the sender follows the MP_xx_NLRI first rule, they sit > on > > top of the rubble and can be recovered. This is a change in the > > standard which one hopes will be implemented and deployed in some > > time. But in any case, the receiver has no way of telling whether > the > > sender intends to follow the rule (or has succeeded !). So, if > the > > receiver does not find MP_xx_NLRI, it may have to assume the > worst. > > > > ...(5) if lost-NLRI are a problem, or a problem worse than > > session-reset, then the receiver appears to be in the unenviable > > position of having to balance the risk/cost of an "incomplete" > > treat-as-withdraw against the benefit of avoiding (the dreaded) > > session-reset. > > > > ...(6) if some/many/most/all lost-NLRI are worse than session- > reset, > > then when can treat-as-withdraw be used ? > > > > At this point I go and hide under my desk. > > > > But, if in practice an UPDATE only ever contains 1 set of NLRI, > then > > my descent into a paranoid, quivering wreck stops at step 2. > Hurrah ! > > > > This is slightly stricter than it needs to be: there is no problem > > with both sets of body-NLRI appearing together. > > > > Now, you can argue that the only thing a receiver *can* do is to > > treat-as-withdraw on the basis of the NLRI it can see, and not > worry > > about things it cannot see -- so that's what it *ought* to do. As > a > > practical matter, errors are rare... errors which result in lost- > NLRI > > are rarer still... the result is probably not as bad as > > session-reset... and the operator should be got out of bed to deal > > with the root-cause pretty sharpish, so any bad effects will be > > temporary... and in any case treat-as-withdraw is not a perfect > > work-around, just the best we have. Trying to decide when it is > more > > or less likely that there are lost-NLRI -- searching through the > > rubble for possible survivors -- looks like a tricky problem, and > best > > avoided. > > > > If, de facto, the receiver can assume that messages contain either > > body-NLRI or just one MP_xx_NLRI attribute, then what the receiver > > *can* do doesn't change, but what it *ought* to do is less > > problematic, and the rationale requires much, much less hand > waving. > > > > It's not necessary for absolutely every sender to be absolutely > > guaranteed to follow this (post hoc) rule. For the minority that > > don't work this way, the hand waving argument may be deployed. > But > > the smaller that minority is, the less vigorous the hand waving > has to > > be to make the point. > > > > For completeness, note that the MP_xx_NLRI at the front rule is > > orthogonal to this. Senders which follow the rule are less likely > to > > generate a broken UPDATE from which the NLRI cannot be recovered. > The > > rule is not relevant to what the receiver does with the UPDATE. > > > > Chris > > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 14 14:03:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E18E1A01B7 for ; Wed, 14 May 2014 14:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXUxtguTlwcU for ; Wed, 14 May 2014 14:03:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) by ietfa.amsl.com (Postfix) with ESMTP id E60621A0129 for ; Wed, 14 May 2014 14:03:34 -0700 (PDT) Received: from [172.29.35.92] (66.129.241.13) by BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 14 May 2014 21:03:25 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <537328F4.1080203@benocs.com> Date: Wed, 14 May 2014 14:03:12 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: <537328F4.1080203@benocs.com> To: X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: DM2PR08CA006.namprd08.prod.outlook.com (10.141.52.164) To BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) X-Forefront-PRVS: 0211965D06 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(164054003)(69224002)(199002)(189002)(377454003)(51704005)(24454002)(83072002)(21056001)(86362001)(77156001)(46406003)(93916002)(101416001)(92566001)(92726001)(85852003)(31966008)(19580395003)(102836001)(87286001)(83716003)(77982001)(88136002)(74662001)(36756003)(74502001)(83322001)(19580405001)(87976001)(50466002)(81342001)(15975445006)(81542001)(62966002)(79102001)(82746002)(23726002)(100916002)(89996001)(4396001)(50986999)(76176999)(42186004)(97756001)(33656001)(50226001)(76482001)(47776003)(20776003)(64706001)(46102001)(80022001)(66066001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB728; H:[172.29.35.92]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/1SqOsukXz4uex4dgUsltAHyo8GQ Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 21:03:38 -0000 Deniz, On May 14, 2014, at 1:27 AM, Deniz Bahadir wrote: > I support making this draft an RFC. >=20 > However, I would like to see the following points addressed before = that. >=20 > 1. > In section 4.2 there are some wrong attribute-names. MP_REACH should = be MP_REACH_NLRI and MP_UNREACH should be MP_UNREACH_NLRI. >=20 > 2. > In section 6.4 there is also a wrong attribute-name. MULTI_EXIT_DESC = should be MULTI_EXIT_DISC. Fixed both the above for forthcoming -09. Thanks. > 3. > Is there a general approach (session-reset, treat-as-withdraw or = attribute-discard) which should be taken if someone finds an = error-situation which is neither covered by this document nor any other = RFC? > Section 7 mentions treat-as-withdraw as preferred approach. However, = that section is "only" a guidance for authors of new BGP specifications. > So maybe one should add the preferred approach in another section, = e.g. in a section 2.1 ("General approach if nothing else applies"). I hesitate to try to be more prescriptive than the draft already is, for = cases which are by definition undefined. One hopes that the implementor = will Do The Right thing, we have pretty strongly indicated what we think = the right thing usually is, but without knowledge of the specific error = case it's hard to say that t-a-w is *definitely* right. > 4. > Section 3.d suggests to use the approach "treat-as-withdraw" if any of = the well-known mandatory attributes are not present. Maybe one should = add an extra note, that this does not apply for NEXT_HOP in the case of = MP_REACH_NLRI being present in the UPDATE-message!? > (I know, this is what RFC 4760 already says, but I think the current = document would be more complete to include this note, too.) Will be incorporated in -09, thanks. > 5. > (This point is probably very controversial.) > If there is no known (up-to-date) implementation (or not even an old = one) which violates the restrictions on MP_REACH_NLRI, MP_UNREACH_NLRI = mentioned at the beginning of section 4, might it be possible to remove = the following sentence which relaxes these restrictions again? > (The sentence in question states: "In all these cases, however, an = implementation MUST still be prepared to receive these fields in any = position or combination.") We've had several indications that these assumptions are not universally = true (exaBGP, BIRD, I believe) so we can't do this. > 6. > I remember to have read somewhere on the Internet or the = IETF-mailing-list that it is current best practice to not send = UPDATE-messages with both, non-empty Withdrawn Routes field and = non-empty Network Layer Reachability Information field, in it = (regardless of the presence of MP_(UN)REACH_NLRI). > Maybe this information should also be included in the beginning of = section 4, which then could become a subsection of its own. Seems like by prescribing this behavior we've got this covered? --John >=20 >=20 > Thanks, > Deniz >=20 >=20 > Am 14.05.2014 02:27, schrieb John G. Scudder: >> Folks, >>=20 >> The version I've just posted incorporates most of the suggestions >> received during the WGLC to date, including: >>=20 >> - Added to the rationale given in the introduction. >> - Refactored and cleaned up (the old) section 2 ("Revision to Base >> Specification"). >> - Further restrictions on where and how NLRI fields can be sent (in >> summary, don't mix your encodings and don't mix MP_REACH and >> MP_UNREACH). These are believed to follow current practice. >> - Attribute length of zero generally disallowed, except in cases = where >> it actually makes sense (ATOMIC_AGGREGATE and sometimes AS_PATH). >> - New "Guidance for Authors of BGP Specifications" section. >>=20 >> And various other bits of polish. Rfcdiff is your friend. >>=20 >> Thanks for all the review so far, it's been very productive. The main >> open issue I'm currently aware of is Bruno's regarding whether we = should >> stop being draconian with MP_{UN}REACH flags. For my part, I take no >> strong position on this and am happy to follow whatever the WG = consensus is. >>=20 >> --John >>=20 >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >>=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 14 14:05:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0D01A01D7; Wed, 14 May 2014 14:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT4gypszjS2D; Wed, 14 May 2014 14:04:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) by ietfa.amsl.com (Postfix) with ESMTP id 14EF91A01B7; Wed, 14 May 2014 14:04:58 -0700 (PDT) Received: from [172.29.35.92] (66.129.241.13) by BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 14 May 2014 21:04:50 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: Date: Wed, 14 May 2014 14:04:40 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Thomas Mangin X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: DM2PR08CA002.namprd08.prod.outlook.com (10.141.52.160) To BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) X-Forefront-PRVS: 0211965D06 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(164054003)(199002)(189002)(377454003)(51704005)(24454002)(83072002)(21056001)(86362001)(77156001)(46406003)(93916002)(101416001)(92566001)(92726001)(85852003)(31966008)(19580395003)(102836001)(87286001)(83716003)(77982001)(88136002)(74662001)(36756003)(74502001)(83322001)(19580405001)(87976001)(50466002)(81342001)(81542001)(62966002)(79102001)(82746002)(23726002)(100916002)(89996001)(4396001)(50986999)(76176999)(42186004)(97756001)(33656001)(50226001)(76482001)(47776003)(20776003)(64706001)(46102001)(80022001)(66066001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB728; H:[172.29.35.92]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/qSgbOZ7I64O0pjgw2_91qEJmOsM Cc: "idr@ietf. org" , idr-bounces@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 21:05:01 -0000 Hi Thomas, On May 14, 2014, at 2:23 AM, Thomas Mangin = wrote: > Sorry for the late comment, I am so late behind my mail. Not at all, your comment is very timely. > Could I just ask you why the document recommend : >=20 > o The MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL > be encoded as the very first path attribute in an UPDATE. >=20 > For the UN_UNREACH_NLRI, I have no question as AFAIU it does not = matter where it is. I see that Chris has answered this exhaustively. I agree with his = analysis. Thanks, --John= From nobody Wed May 14 15:55:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7403A1A0345 for ; Wed, 14 May 2014 15:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAxzJdlHfLKc for ; Wed, 14 May 2014 15:54:56 -0700 (PDT) Received: from mail.crfreenet.org (mail6.crfreenet.org [IPv6:2002:515c:9101:20::10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3308E1A035D for ; Wed, 14 May 2014 15:54:53 -0700 (PDT) Received: from localhost (ip-89-102-22-52.net.upcbroadband.cz [89.102.22.52]) by mail.crfreenet.org (Postfix) with ESMTP id E831DFCCD; Thu, 15 May 2014 00:54:42 +0200 (CEST) Received: from santiago by localhost with local (Exim 4.69) (envelope-from ) id 1WkifJ-0005Sn-1G; Thu, 15 May 2014 01:32:49 +0200 Date: Thu, 15 May 2014 01:32:48 +0200 From: Ondrej Zajicek To: "John G. Scudder" Message-ID: <20140514233248.GD12659@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Operating-System: Debian GNU/Linux User-Agent: Mutt/1.5.18 (2008-05-17) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/KjyBLCDI1DEcLCwbVgWHd257mVY Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 22:55:02 -0000 On Tue, May 13, 2014 at 05:27:54PM -0700, John G. Scudder wrote: > Folks, >=20 > The version I've just posted incorporates most of the suggestions receive= d during the WGLC to date, including: >=20 > - Added to the rationale given in the introduction. > - Refactored and cleaned up (the old) section 2 ("Revision to Base Specif= ication"). > - Further restrictions on where and how NLRI fields can be sent (in summa= ry, don't mix your encodings and don't mix MP_REACH and MP_UNREACH). These = are believed to follow current practice. > - Attribute length of zero generally disallowed, except in cases where it= actually makes sense (ATOMIC_AGGREGATE and sometimes AS_PATH). > - New "Guidance for Authors of BGP Specifications" section. Hello I have another two minor comments: 3. c. Attribute Flag error handling: Formulation "If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code" is IMHO a bit vague about which flags could be in conflict with the attribute code. Optional (O) and Transitive (T) bits clearly could, undefined bits cleary couldn't, but i am not sure about Partial and and Extended Legth. (e.g. if there is 300B long AGGREGATOR with Extended Length flag, should it be just discarded according to 6.7. based on its length, or should it be treat-as-withdraw according by 3. c. because AGGREGATOR should not ever have Extended Length flag set?) Should the zeroness of Partial (P) bit for other than optional transitive atributes be checked? For all or just for recognized attributes? And what if i receive unrecognized attribute without optional flag? That is cleary broken but not covered by the formulation from the draft (or from the RFC 4271). IMHO, O bit and consistency of O-T-P bits (i.e. no partial unless optional transitive) should be checked for all atributes, additionally T bit should be checked for recognized attributes. EL bit should not be checked (should be considered intependently on attribute type). 4.2 Syntactic Correctness of NLRI Fields What about the Next Hop field in MP_REACH_NLRI? Although specifying syntactic correctness for all possible AFIs is out of scope of the draft, the draft could say in 4.2 how errors of the Next hop field should be generally handled. Although the draft handles errors in MP_REACH_NLRI by session-reset, i would suggest that errors in the Next Hop field of MP_REACH_NLRI should be handled by treat-as-withdraw (as long as NLRI part of MP_REACH_NLRI is parsed without errors). > The main open issue I'm currently aware of is Bruno's regarding > whether we should stop being draconian with MP_{UN}REACH flags. For my > part, I take no strong position on this and am happy to follow whatever > the WG consensus is. I tend to agree with Bruno. Special handling of MP_{UN}REACH flags seems unnecessary. --=20 Ondrej 'Santiago' Zajicek From nobody Thu May 15 07:26:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CA01A00B9 for ; Thu, 15 May 2014 07:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnyKRqqP6NeX for ; Thu, 15 May 2014 07:26:00 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 24E9D1A0085 for ; Thu, 15 May 2014 07:26:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E4D62C23D; Thu, 15 May 2014 10:25:52 -0400 (EDT) Date: Thu, 15 May 2014 10:25:52 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20140515142552.GD17907@pfrc> References: <7176992A-CE2F-45E1-8C27-E61465E55A50@juniper.net> <201405141549.s4EFnFYB021928@maildrop2.v6ds.occnc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HsPctyc29jyXymUWDEEmf6fupD8 Cc: "idr@ietf. org" , govindan@isi.edu, guban@microsoft.com, Ravi Chandra , RFC Errata System , Hares Susan Subject: Re: [Idr] [Technical Errata Reported] RFC2439 (3964) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 14:26:02 -0000 On Wed, May 14, 2014 at 01:14:11PM -0400, Alia Atlas wrote: > It is excellent to push well implemented and understood RFCs to a Full Standard. I support Curtis' comments: The document is need of a re-write. Many of the ideas are used in various implementations, but I'm not aware of anyone that faithfully implements the details about how flaps are counted. If anything, we'd need to document what people did, let that sit around long enough to be considered proposed. :-) The motivation for moving it along the standards track are rather low since in general (modulo Randy Bush's rfd-usable I-D that's in the RFC Editor's queue) the feature is not recommended. -- Jeff > > Alia > > On Wed, May 14, 2014 at 11:49 AM, Curtis Villamizar > wrote: > > > > John, Gunjan, > > > > John is correct on both points. The document lacks clarity in > > general, and the reuse list is used for both reachable and unreachable > > routes, disposing of all history associated with the route if it > > unreachable. > > > > Two structures could have been used but it is computationally more > > efficient to have one slightly more dense data structure than two > > slightly more sparse data structures. Except for the sentence that > > John pointed to the document is not clear about this. > > > > A rewrite of RFC2439 is long overdue but would risk reigniting old > > flame wars. If the rewrite was clear about deployment experience > > section were clear about the problems that have occurred, then the > > flame wars might not be so intense. > > > > Curtis > > > > > > In message <7176992A-CE2F-45E1-8C27-E61465E55A50@juniper.net> > > "John G. Scudder" writes: > >> > >> Hi Gunjan, > >> > >> RFC 2439 isn't the easiest to read, but according to my reading this erratum is not correct. Despite its name, the "reuse list" as described in S. 4.8.7 is used for processing timer-driven events in general, including freeing up damping structures ("histories"). Quoting from S. 4.8.7, "Handling Reuse Timer Events": > >> > >> all of the routes in the first queue will be > >> available for immediate reuse if reachable or the history entry could > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> be disposed of if unreachable. > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >> If you have any doubt that "history" means "damping structure", take a look at S. 4.8.2: > >> > >> If there is no previous stability history (the damping structure > >> pointer is zero), then: > >> > >> I assume you're clear on why histories for unreachable routes need to be maintained to begin with. > >> > >> I'm going to recommend to the AD that this erratum be rejected, unless you or someone else wants to make a case why it shouldn't be. > >> > >> Thanks, > >> > >> --John > >> > >> On Apr 15, 2014, at 10:36 AM, RFC Errata System wrote: > >> > >> > The following errata report has been submitted for RFC2439, > >> > "BGP Route Flap Damping". > >> > > >> > -------------------------------------- > >> > You may review the report below and at: > >> > http://www.rfc-editor.org/errata_search.php?rfc=2439&eid=3964 > >> > > >> > -------------------------------------- > >> > Type: Technical > >> > Reported by: Gunjan Bansal > >> > > >> > Section: 4.8.2 > >> > > >> > Original Text > >> > ------------- > >> > In either case then: > >> > > >> > 1. set t-updated = t-now > >> > > >> > 2. insert into a reuse list (see Section 4.8.6) > >> > > >> > Corrected Text > >> > -------------- > >> > In either case then: > >> > > >> > 1. set t-updated = t-now > >> > > >> > > >> > Notes > >> > ----- > >> > The route which is unreachable should NOT be inserted into the reuse-list. reuse-list (as per explanation in Section 4.8.7) is used for fast evaluation of routes which have been suppressed long enough and can be potentially used again. The "unreachability/withdrawal" of route is never suppressed and never needs to be re-evaluated in future. > >> > > >> > Instructions: > >> > ------------- > >> > This errata is currently posted as "Reported". If necessary, please > >> > use "Reply All" to discuss whether it should be verified or > >> > rejected. When a decision is reached, the verifying party (IESG) > >> > can log in to change the status and edit the report, if necessary. > >> > > >> > -------------------------------------- > >> > RFC2439 (no draft string recorded) > >> > -------------------------------------- > >> > Title : BGP Route Flap Damping > >> > Publication Date : November 1998 > >> > Author(s) : C. Villamizar, R. Chandra, R. Govindan > >> > Category : PROPOSED STANDARD > >> > Source : Inter-Domain Routing > >> > Area : Routing > >> > Stream : IETF > >> > Verifying Party : IESG > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 15 08:02:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849C01A0099 for ; Thu, 15 May 2014 08:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ien-blfAVM9c for ; Thu, 15 May 2014 08:01:59 -0700 (PDT) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id 044E61A0092 for ; Thu, 15 May 2014 08:01:59 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta06.emeryville.ca.mail.comcast.net with comcast id 2Cb41o0020S2fkCA6F1szz; Thu, 15 May 2014 15:01:52 +0000 Received: from [192.168.1.2] ([67.188.232.210]) by omta09.emeryville.ca.mail.comcast.net with comcast id 2F1o1o0034Z1nl78VF1o2d; Thu, 15 May 2014 15:01:51 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Tony Li In-Reply-To: <20140515142552.GD17907@pfrc> Date: Thu, 15 May 2014 08:01:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <909D9C88-1A08-4E8A-9151-DD2A8AFD6662@tony.li> References: <7176992A-CE2F-45E1-8C27-E61465E55A50@juniper.net> <201405141549.s4EFnFYB021928@maildrop2.v6ds.occnc.com> <20140515142552.GD17907@pfrc> To: Jeff Haas X-Mailer: Apple Mail (2.1874) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1400166112; bh=0J1tYieLVkggL2w1oE4jOl6Lzm/duDJgBk1Go9zgd+Y=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=OGCg7jfbVRtYJsnriqN7CioNZtT7NWhgAYpSRlw0l3aJmqYJp9fmSwpd+kbDNh2Bg bp69ZDPE2nQdJSHqeRw73jZtdQwaV6V8+P4+5wov/j608Ar65qPEzBc8QRlNNeZQgN Oidq9ECCOHG4IsPbP7qQBXg3XB1zPlnNO+lxDo61MnSb9Xu4RLN03Qs5LDaTqbKkKF igo7CN025HhCGY3jVb9Qs/YBQ5LE4hMALY2S56uxFVaYuCL2KtxeiRm/NX9TzFangQ FIVY9kCTUYsvEq5vKNwIlmiDBlNPrqKc3khnNKd35AkVaZl1QQZgY2HT/FTkLVkiI5 0ygB7s7i8dsnA== Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AS9gy52qFcSYl7Tu4Bbbpa874Zc Cc: "idr@ietf. org" , govindan@isi.edu, guban@microsoft.com, Ravi Chandra , Hares Susan , RFC Errata System Subject: Re: [Idr] [Technical Errata Reported] RFC2439 (3964) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 15:02:00 -0000 On May 15, 2014, at 7:25 AM, Jeffrey Haas wrote: > The motivation for moving it along the standards track are rather low = since > in general (modulo Randy Bush's rfd-usable I-D that's in the RFC = Editor's > queue) the feature is not recommended. If anything, someone should write an RFC describing all of the problems = with this idea and moving the document to =91Historical=92. Tony From nobody Thu May 15 22:41:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954771A012D; Thu, 15 May 2014 22:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH9Cfo5mXJ_P; Thu, 15 May 2014 22:41:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BFD1A0118; Thu, 15 May 2014 22:41:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140516054150.29163.97279.idtracker@ietfa.amsl.com> Date: Thu, 15 May 2014 22:41:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jrTR5Ge9LaxiuqbG1iIOnkm0Lhc Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 05:41:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Notification Message support for BGP Graceful Restart Authors : Keyur Patel Rex Fernando John Scudder Jeff Haas Filename : draft-ietf-idr-bgp-gr-notification-02.txt Pages : 7 Date : 2014-05-15 Abstract: The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 16 03:55:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CD51A020D for ; Fri, 16 May 2014 03:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x16-aRFfMwxi for ; Fri, 16 May 2014 03:55:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4536D1A0209 for ; Fri, 16 May 2014 03:55:12 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C37AFC1B7; Fri, 16 May 2014 06:55:04 -0400 (EDT) Date: Fri, 16 May 2014 06:55:04 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20140516105504.GA17496@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/x8ZyFNw9qkxzGCjmdwZBiapRbqE Subject: [Idr] WGLC requested for draft-ietf-idr-bgp-gr-notification X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 10:55:14 -0000 Working Group, The authors of draft-ietf-idr-bgp-gr-notification would like to request working group last call for this document. The most recent changes reflect implementation experience and some word smithing. There is also a minor clarification in the NOTIFICATION message with respect to including a data byte so the original reason for the event can be propagated. (See sec. 3.1 in the diff.) -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- Date: Thu, 15 May 2014 22:41:50 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-gr-notification-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Notification Message support for BGP Graceful Restart Authors : Keyur Patel Rex Fernando John Scudder Jeff Haas Filename : draft-ietf-idr-bgp-gr-notification-02.txt Pages : 7 Date : 2014-05-15 Abstract: The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-gr-notification/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-gr-notification-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ----- End forwarded message ----- From nobody Fri May 16 15:03:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15E51A0152; Fri, 16 May 2014 15:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FReIfLsWNRjt; Fri, 16 May 2014 15:03:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id D5B3C1A00E5; Fri, 16 May 2014 15:03:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id ECAF118000D; Fri, 16 May 2014 15:02:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140516220224.ECAF118000D@rfc-editor.org> Date: Fri, 16 May 2014 15:02:24 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/gFbwZMJBq1K21gWKYB49Vi0crU0 Cc: drafts-update-ref@iana.org, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 7196 on Making Route Flap Damping Usable X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 22:03:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7196 Title: Making Route Flap Damping Usable Author: C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. Maennel Status: Standards Track Stream: IETF Date: May 2014 Mailbox: cristel@iij.ad.jp, randy@psg.com, keyupate@cisco.com, mpradosh@yahoo.com, o@maennel.net Pages: 8 Characters: 15202 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-rfd-usable-04.txt URL: http://www.rfc-editor.org/rfc/rfc7196.txt Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process. This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat May 17 13:01:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C501A01EB for ; Sat, 17 May 2014 13:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.153 X-Spam-Level: X-Spam-Status: No, score=-1.153 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsz4C8LRGxio for ; Sat, 17 May 2014 13:01:49 -0700 (PDT) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B9A1A01E7 for ; Sat, 17 May 2014 13:01:48 -0700 (PDT) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s4HJoLsi050339; Sat, 17 May 2014 15:50:21 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201405171950.s4HJoLsi050339@maildrop2.v6ds.occnc.com> To: Tony Li From: Curtis Villamizar In-reply-to: Your message of "Thu, 15 May 2014 08:01:47 -0700." <909D9C88-1A08-4E8A-9151-DD2A8AFD6662@tony.li> Date: Sat, 17 May 2014 15:50:21 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/IP6wVVPp7q_4twSFoWhkMOhpJ44 Cc: "idr@ietf. org" , govindan@isi.edu, guban@microsoft.com, Ravi Chandra , Hares Susan , RFC Errata System Subject: Re: [Idr] [Technical Errata Reported] RFC2439 (3964) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 20:01:55 -0000 In message <909D9C88-1A08-4E8A-9151-DD2A8AFD6662@tony.li> Tony Li writes: > > On May 15, 2014, at 7:25 AM, Jeffrey Haas wrote: > > > The motivation for moving it along the standards track are rather low since > > in general (modulo Randy Bush's rfd-usable I-D that's in the RFC Editor's > > queue) the feature is not recommended. > > > If anything, someone should write an RFC describing all of the > problems with this idea and moving the document to "Historical". > > Tony It is still in use. We should document that some of the problems, perhaps most, have to do with one major vendor not following the "per path" recommendation in the draft and another major vendor following suit. Memory is no longer as tight as it was in 1995 so the excuse to keep only "per destination" state is rather weak. Curtis From nobody Mon May 19 08:05:43 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56AD1A0117 for ; Mon, 19 May 2014 08:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AlxhnudFBHp for ; Mon, 19 May 2014 08:05:37 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id 50F4D1A0193 for ; Mon, 19 May 2014 08:04:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 6382E6420CF; Mon, 19 May 2014 17:04:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmZDNqT0n1s1; Mon, 19 May 2014 17:04:28 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 86AFD6420CE; Mon, 19 May 2014 17:04:28 +0200 (CEST) Message-ID: <537A1D7C.7000809@benocs.com> Date: Mon, 19 May 2014 17:04:28 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: idr@ietf.org References: <537328F4.1080203@benocs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/MXWnw9pzZBGGgn1ptSncTZMmZ1g Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 15:05:40 -0000 >> 3. >> Is there a general approach (session-reset, treat-as-withdraw or attribute-discard) which should be taken if someone finds an error-situation which is neither covered by this document nor any other RFC? >> Section 7 mentions treat-as-withdraw as preferred approach. However, that section is "only" a guidance for authors of new BGP specifications. >> So maybe one should add the preferred approach in another section, e.g. in a section 2.1 ("General approach if nothing else applies"). > > I hesitate to try to be more prescriptive than the draft already is, for cases which are by definition undefined. One hopes that the implementor will Do The Right thing, we have pretty strongly indicated what we think the right thing usually is, but without knowledge of the specific error case it's hard to say that t-a-w is *definitely* right. That's fine with me. However, having RFC 4271 in mind, my first reflex is still to send a NOTIFICATION in such a situation. (I probably need to retrain my reflexes. ;-) >> 5. >> (This point is probably very controversial.) >> If there is no known (up-to-date) implementation (or not even an old one) which violates the restrictions on MP_REACH_NLRI, MP_UNREACH_NLRI mentioned at the beginning of section 4, might it be possible to remove the following sentence which relaxes these restrictions again? >> (The sentence in question states: "In all these cases, however, an implementation MUST still be prepared to receive these fields in any position or combination.") > > We've had several indications that these assumptions are not universally true (exaBGP, BIRD, I believe) so we can't do this. OK, I see. But how about being at least strict with the third point? As far as I understand, there seems to be no implementation which mixes both, Multi-Protocol NLRI information (MP_REACH_NLRI and/or MP_UNREACH_NLRI) with traditional NLRI information (Withdrawn Routes field and/or Network Layer Reachability Information field). >> 6. >> I remember to have read somewhere on the Internet or the IETF-mailing-list that it is current best practice to not send UPDATE-messages with both, non-empty Withdrawn Routes field and non-empty Network Layer Reachability Information field, in it (regardless of the presence of MP_(UN)REACH_NLRI). >> Maybe this information should also be included in the beginning of section 4, which then could become a subsection of its own. > > Seems like by prescribing this behavior we've got this covered? Sorry, I am not entirely sure how I have to interpret this answer? Sadly, I also could not find the source of my claim for the existence of said "current best practice". (Maybe it is no best practice at all?) However, if it does not break anything I would prefer to see it merged with the three points at the beginning of section 4. Ondrej's merge-example sounds good to me. For the sake of completeness I repeat it here: An UPDATE message MUST NOT contain more than one of the following: non-empty Withdrawn Routes field, non-empty Network Layer Reachability Information field, MP_REACH_NLRI attribute, and MP_UNREACH_NLRI attribute. Deniz From nobody Mon May 19 10:45:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47FD1A032A for ; Mon, 19 May 2014 10:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQKRUBQ7q_Me for ; Mon, 19 May 2014 10:45:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58AE1A00B1 for ; Mon, 19 May 2014 10:45:01 -0700 (PDT) Received: from [172.29.33.246] (66.129.241.15) by BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) with Microsoft SMTP Server (TLS) id 15.0.944.11; Mon, 19 May 2014 17:44:54 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <537A1D7C.7000809@benocs.com> Date: Mon, 19 May 2014 13:44:43 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <537328F4.1080203@benocs.com> <537A1D7C.7000809@benocs.com> To: X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.15] X-ClientProxiedBy: BY2PR02CA015.namprd02.prod.outlook.com (10.242.234.143) To BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) X-Forefront-PRVS: 021670B4D2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(24454002)(164054003)(51704005)(377454003)(199002)(189002)(21056001)(50986999)(19580405001)(76176999)(83322001)(19580395003)(87976001)(101416001)(46102001)(81342001)(89996001)(36756003)(83072002)(50226001)(85852003)(4396001)(99396002)(93916002)(74502001)(83716003)(86362001)(80022001)(92566001)(92726001)(88136002)(50466002)(31966008)(66066001)(77982001)(81542001)(77156001)(23756003)(20776003)(47776003)(64706001)(42186004)(33656001)(79102001)(76482001)(57306001)(102836001)(82746002)(62966002)(87286001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB724; H:[172.29.33.246]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/NVCBaj4DqnMjMPHRiMppvYqjIP8 Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 17:45:03 -0000 On May 19, 2014, at 11:04 AM, Deniz Bahadir = wrote: >>> 5. >>> (This point is probably very controversial.) >>> If there is no known (up-to-date) implementation (or not even an old = one) which violates the restrictions on MP_REACH_NLRI, MP_UNREACH_NLRI = mentioned at the beginning of section 4, might it be possible to remove = the following sentence which relaxes these restrictions again? >>> (The sentence in question states: "In all these cases, however, an = implementation MUST still be prepared to receive these fields in any = position or combination.") >>=20 >> We've had several indications that these assumptions are not = universally true (exaBGP, BIRD, I believe) so we can't do this. >=20 > OK, I see. But how about being at least strict with the third point? = As far as I understand, there seems to be no implementation which mixes = both, Multi-Protocol NLRI information (MP_REACH_NLRI and/or = MP_UNREACH_NLRI) with traditional NLRI information (Withdrawn Routes = field and/or Network Layer Reachability Information field). I take your point. However, since (prior to this draft) the combination = of MP and legacy NLRI encodings was not forbidden, it still seems = prudent to consider that they MIGHT be mixed even if nobody has admitted = to it on-list.=20 But suppose the text were written differently, such that the final case = was "less strict". What would the implementation do differently?=20 My thinking in writing that sentence was basically to caution = implementors, "just because the error-handling spec says 'don't do these = things' doesn't mean it would be a good idea for your implementation to = break if they happen anyway". This is basically the process of = deprecating an old behavior -- first you forbid it but make sure it = continues to be accepted on input anyway. Much later, you can consider = making it a protocol error. If you have text you'd like to propose, please do. Thanks, --John= From nobody Mon May 19 10:53:43 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5722B1A00B1 for ; Mon, 19 May 2014 10:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtDxkKOmQSIU for ; Mon, 19 May 2014 10:53:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82ED21A011A for ; Mon, 19 May 2014 10:53:25 -0700 (PDT) Received: from [172.29.33.246] (66.129.241.15) by BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) with Microsoft SMTP Server (TLS) id 15.0.944.11; Mon, 19 May 2014 17:53:23 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <537A1D7C.7000809@benocs.com> Date: Mon, 19 May 2014 13:53:13 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <537328F4.1080203@benocs.com> <537A1D7C.7000809@benocs.com> To: X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.15] X-ClientProxiedBy: BY2PR02CA013.namprd02.prod.outlook.com (10.242.234.141) To BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) X-Forefront-PRVS: 021670B4D2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(24454002)(164054003)(51704005)(377454003)(199002)(189002)(21056001)(50986999)(19580405001)(76176999)(83322001)(19580395003)(87976001)(101416001)(46102001)(81342001)(89996001)(36756003)(83072002)(50226001)(85852003)(4396001)(99396002)(93916002)(74502001)(83716003)(86362001)(80022001)(92566001)(92726001)(88136002)(50466002)(31966008)(66066001)(77982001)(81542001)(77156001)(23756003)(20776003)(47776003)(64706001)(42186004)(33656001)(79102001)(76482001)(57306001)(102836001)(82746002)(62966002)(87286001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB724; H:[172.29.33.246]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/EpMUV4r9w8_YSb49Wi0rWus8XgU Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 17:53:41 -0000 On May 19, 2014, at 11:04 AM, Deniz Bahadir = wrote: >>> 6. >>> I remember to have read somewhere on the Internet or the = IETF-mailing-list that it is current best practice to not send = UPDATE-messages with both, non-empty Withdrawn Routes field and = non-empty Network Layer Reachability Information field, in it = (regardless of the presence of MP_(UN)REACH_NLRI). >>> Maybe this information should also be included in the beginning of = section 4, which then could become a subsection of its own. >>=20 >> Seems like by prescribing this behavior we've got this covered? >=20 > Sorry, I am not entirely sure how I have to interpret this answer? I meant, since error-handling mandates that you can't combine NLRI = fields, I don't see a benefit to saying that not combining them was = already best practice? (Notwithstanding the fact neither you nor I can = document that best practice claim.) > Sadly, I also could not find the source of my claim for the existence = of said "current best practice". (Maybe it is no best practice at all?) = However, if it does not break anything I would prefer to see it merged = with the three points at the beginning of section 4. I don't think making this claim would break anything, but I don't see = what it would help either, so I would prefer to leave it out rather than = make the document longer. Maybe you could explain how it would help, = keeping in mind the primary purpose of the document is to be a protocol = spec, i.e. to tell the implementor what to do. > Ondrej's merge-example sounds good to me. > For the sake of completeness I repeat it here: >=20 > An UPDATE message MUST NOT contain more than one of the following: > non-empty Withdrawn Routes field, non-empty Network Layer = Reachability > Information field, MP_REACH_NLRI attribute, and MP_UNREACH_NLRI > attribute. I will do that (or similar) for -09. Thanks, --John= From nobody Mon May 19 11:10:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A011A03AB for ; Mon, 19 May 2014 11:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nunkrVnaampo for ; Mon, 19 May 2014 11:10:43 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id 08B1C1A03AD for ; Mon, 19 May 2014 11:10:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id F097A6420D0; Mon, 19 May 2014 20:10:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00HDs5yvkWrE; Mon, 19 May 2014 20:10:32 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 27C156420CF; Mon, 19 May 2014 20:10:32 +0200 (CEST) Message-ID: <537A4918.70304@benocs.com> Date: Mon, 19 May 2014 20:10:32 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "John G. Scudder" References: <537328F4.1080203@benocs.com> <537A1D7C.7000809@benocs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/3uGSaX5woyL5JuTlYs95E6v0K1c Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 18:10:45 -0000 Hi John, >>>> 5. >>>> (This point is probably very controversial.) [snip] >> OK, I see. But how about being at least strict with the third point? As far as I understand, there seems to be no implementation which mixes both, Multi-Protocol NLRI information (MP_REACH_NLRI and/or MP_UNREACH_NLRI) with traditional NLRI information (Withdrawn Routes field and/or Network Layer Reachability Information field). > > I take your point. However, since (prior to this draft) the combination of MP and legacy NLRI encodings was not forbidden, it still seems prudent to consider that they MIGHT be mixed even if nobody has admitted to it on-list. > > But suppose the text were written differently, such that the final case was "less strict". What would the implementation do differently? Makes sense. I just thought that being less vague would make it much easier for implementers (like me ;-). But I understand, that it might lead to practical problems. (That's possibly the down-side of allowing too much interpretation in the first-place.) > My thinking in writing that sentence was basically to caution implementors, "just because the error-handling spec says 'don't do these things' doesn't mean it would be a good idea for your implementation to break if they happen anyway". This is basically the process of deprecating an old behavior -- first you forbid it but make sure it continues to be accepted on input anyway. Much later, you can consider making it a protocol error. Agreed. So I count this as the beginning of the deprecation-process. I guess, complete removal could then take place in an entirely new version of the BGP base-RFC. (Maybe, BGP5? This seems far enough in the future. ;-) > If you have text you'd like to propose, please do. I am sorry, currently I do not have any text to propose. But I will consider that for the future. Deniz From nobody Mon May 19 11:56:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70B21A02B9 for ; Mon, 19 May 2014 11:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Drf0cICAqCua for ; Mon, 19 May 2014 11:56:11 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id A736B1A03BD for ; Mon, 19 May 2014 11:55:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 374B46420CF; Mon, 19 May 2014 20:45:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X9ZUC48bhZg; Mon, 19 May 2014 20:45:22 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 0E1A16401FF; Mon, 19 May 2014 20:45:22 +0200 (CEST) Message-ID: <537A5142.7020009@benocs.com> Date: Mon, 19 May 2014 20:45:22 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "John G. Scudder" References: <537328F4.1080203@benocs.com> <537A1D7C.7000809@benocs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/3tne4GpHeSkFn6yDBFmpAP3UpHo Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 18:56:12 -0000 >>>> 6. [snip] >>> Seems like by prescribing this behavior we've got this covered? >> >> Sorry, I am not entirely sure how I have to interpret this answer? > > I meant, since error-handling mandates that you can't combine NLRI fields, I don't see a benefit to saying that not combining them was already best practice? (Notwithstanding the fact neither you nor I can document that best practice claim.) OK, that's right. I just thought that if someone knew the source of this best-practice claim one could reference and repeat it in this document as it seems to be addressed, too. But because no-one knows if and where this claim was made before (if at all), it is probably better to not mention it. >> Sadly, I also could not find the source of my claim for the existence of said "current best practice". (Maybe it is no best practice at all?) However, if it does not break anything I would prefer to see it merged with the three points at the beginning of section 4. > > I don't think making this claim would break anything, but I don't see what it would help either, so I would prefer to leave it out rather than make the document longer. Maybe you could explain how it would help, keeping in mind the primary purpose of the document is to be a protocol spec, i.e. to tell the implementor what to do. The idea behind it was that as the current document already lists (new) requirements for the four different NLRI fields one could keep the direct interaction of them to a minimum. The current version 8 of the draft says that MP_REACH_NLRI must be alone and that MP_UNREACH_NLRI must be alone. But then why not force the traditional NLRI and traditional Withdrawn Routes to be alone, too? It was just for having similar requirements for similar things and therefore also reducing the parts in the spec which allow too much interpretation for the implementer. As a side-note: For me, as an implementer of such specs, if I stumble across a spec which lets too much room for interpretation, it always means either extra implementation-work (or less optimization-possibilities) to cover all possible (interpretation-)cases, or being afraid that my implementation might break under some special conditions. >> Ondrej's merge-example sounds good to me. [snip] > I will do that (or similar) for -09. I am looking forward to -09 and would be glad to comment on it (and thereby hopefully not annoy anyone). Deniz From nobody Mon May 19 12:34:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A8B1A02DF; Mon, 19 May 2014 12:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URaj5SszSyzp; Mon, 19 May 2014 12:33:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCDE1A03A9; Mon, 19 May 2014 12:33:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> Date: Mon, 19 May 2014 12:33:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/N6LjhROMKZW4psF61U7hOP6auhU Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 19:33:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Revised Error Handling for BGP UPDATE Messages Authors : Enke Chen Juniper Networks Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-09.txt Pages : 14 Date : 2014-05-19 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760 and 5701. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 19 12:52:04 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9D71A03BD for ; Mon, 19 May 2014 12:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejpfV4Os9h5D for ; Mon, 19 May 2014 12:51:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3952E1A03D4 for ; Mon, 19 May 2014 12:51:59 -0700 (PDT) Received: from [172.29.33.246] (66.129.241.10) by BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) with Microsoft SMTP Server (TLS) id 15.0.944.11; Mon, 19 May 2014 19:51:51 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "John G. Scudder" In-Reply-To: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> Date: Mon, 19 May 2014 15:51:39 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1874) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR01CA004.prod.exchangelabs.com (10.255.223.162) To BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) X-Forefront-PRVS: 021670B4D2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(6049001)(428001)(189002)(199002)(51704005)(24454002)(377454003)(377424004)(164054003)(76482001)(15975445006)(57306001)(74662001)(31966008)(42186004)(46102001)(87976001)(74502001)(4396001)(46406003)(83716003)(21056001)(33656001)(77982001)(87286001)(50226001)(19580405001)(83322001)(81542001)(19580395003)(62966002)(81342001)(23726002)(83072002)(15202345003)(85852003)(89996001)(97756001)(76176999)(88136002)(50986999)(99396002)(47776003)(20776003)(64706001)(100916002)(79102001)(101416001)(80022001)(66066001)(93916002)(86362001)(77156001)(82746002)(102836001)(92566001)(92726001)(36756003)(50466002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB724; H:[172.29.33.246]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/zcCINXGhj-OaJzNvhusdP1Efoag Subject: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 19:52:04 -0000 There are just a few relatively small changes in this version: - Note that when MP-BGP is in use, NEXT_HOP is discretionary. - Better text for NLRI section (thanks to Ondrej). - Fix typos. With luck, we are spiraling in to a final version. Thanks, all.=20 --John On May 19, 2014, at 3:33 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Inter-Domain Routing Working Group of = the IETF. >=20 > Title : Revised Error Handling for BGP UPDATE = Messages > Authors : Enke Chen > Juniper Networks > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-09.txt > Pages : 14 > Date : 2014-05-19 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not = only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. >=20 > This document updates error handling for RFCs 1997, 4271, 4360, = 4456, > 4760 and 5701. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 20 00:19:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC511A030F for ; Tue, 20 May 2014 00:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bko9rTmvzvOq for ; Tue, 20 May 2014 00:19:16 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id 407281A029E for ; Tue, 20 May 2014 00:19:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 2995464208F; Tue, 20 May 2014 09:19:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rTVqZHsg9Nm; Tue, 20 May 2014 09:19:10 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 75F01641FF9 for ; Tue, 20 May 2014 09:19:10 +0200 (CEST) Message-ID: <537B01EF.1000802@benocs.com> Date: Tue, 20 May 2014 09:19:11 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: idr@ietf.org References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> In-Reply-To: <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/y7lS_u--lC9VoBC709wzTOjyCbk Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 07:19:18 -0000 I have nothing to complain or to add. Therefore, I support this draft being the final version and becoming an RFC. Thanks for the good work, Deniz Am 19.05.2014 21:51, schrieb John G. Scudder: > There are just a few relatively small changes in this version: > > - Note that when MP-BGP is in use, NEXT_HOP is discretionary. > - Better text for NLRI section (thanks to Ondrej). > - Fix typos. > > With luck, we are spiraling in to a final version. > > Thanks, all. > > --John > > On May 19, 2014, at 3:33 PM, 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 Inter-Domain Routing Working Group of the IETF. >> >> Title : Revised Error Handling for BGP UPDATE Messages >> Authors : Enke Chen >> Juniper Networks >> Pradosh Mohapatra >> Keyur Patel >> Filename : draft-ietf-idr-error-handling-09.txt >> Pages : 14 >> Date : 2014-05-19 >> >> Abstract: >> According to the base BGP specification, a BGP speaker that receives >> an UPDATE message containing a malformed attribute is required to >> reset the session over which the offending attribute was received. >> This behavior is undesirable as a session reset would impact not only >> routes with the offending attribute, but also other valid routes >> exchanged over the session. This document partially revises the >> error handling for UPDATE messages, and provides guidelines for the >> authors of documents defining new attributes. Finally, it revises >> the error handling procedures for a number of existing attributes. >> >> This document updates error handling for RFCs 1997, 4271, 4360, 4456, >> 4760 and 5701. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-error-handling-09 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-09 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > From nobody Tue May 20 11:39:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3D71A02A6 for ; Tue, 20 May 2014 11:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWkDvV5i-Key for ; Tue, 20 May 2014 11:39:40 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3F71A0398 for ; Tue, 20 May 2014 11:39:39 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Wmowo-0000IR-GF for idr@ietf.org; Tue, 20 May 2014 18:39:34 +0000 From: "Chris Hall" To: "'idr@ietf. org'" References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> In-Reply-To: <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> Date: Tue, 20 May 2014 19:39:28 +0100 Organization: Highwayman Message-ID: <021101cf745a$d7fa2f90$87ee8eb0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHq8GuwBYAROfMVxoWKkdFU2NUYygIe4lDJmwHMbfA= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/y9q3UkyzEDl48fwpyHVcljbakeI Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 18:39:41 -0000 John G. Scudder wrote (on Mon 19-May-2014 at 20:52 +0100): ... > - Note that when MP-BGP is in use, NEXT_HOP is discretionary. > - Better text for NLRI section (thanks to Ondrej). > - Fix typos. > > With luck, we are spiraling in to a final version. The requirement to put MP_xxx_NLRI as the first attribute appears to have gone walk-about ? So... treat-as-withdraw is to be applied to whatever (valid) NLRI the receiver manages to find. If there are lost-NLRI, tant pis, go ahead and do an "incomplete" treat-as-withdraw. If no NLRI whatsoever can be found, then the receiver SHALL treat-as-withdraw an empty set of NLRI. Yes ? I accept that the receiver cannot do anything about lost-NLRI, not least because (in the general case) it cannot tell whether there are any ! However, unless somebody knows better, it appears that existing implementations currently: * send at most 2 sets of NLRI in an UPDATE * never mix MP_xx_NLRI attributes with non-empty Withdrawn Routes or NLRI fields. * send an MP_UNREACH_NLRI as the first (and possibly only) attribute. This does not change what the receiver can do... ... but given that the likelihood of lost-NLRI is (in practice) effectively zero, one can ignore the impact of "incomplete" treat-as-withdraw (whatever that might be). This seems to me worth covering in the draft... unless the impact of "incomplete" treat-as-withdraw is deemed negligible -- in which case it seems to me *that* would be worth covering too. Chris From nobody Tue May 20 13:29:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE0F1A0090; Tue, 20 May 2014 13:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzm1FBYRcHBD; Tue, 20 May 2014 13:29:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 979C81A075C; Tue, 20 May 2014 13:29:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140520202928.21398.38962.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 13:29:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/yOHX6tMmnks1OObGr2bNfjEYkW4 Cc: idr mailing list , idr chair , RFC Editor Subject: [Idr] Protocol Action: 'The Accumulated IGP Metric Attribute for BGP' to Proposed Standard (draft-ietf-idr-aigp-18.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:29:33 -0000 The IESG has approved the following document: - 'The Accumulated IGP Metric Attribute for BGP' (draft-ietf-idr-aigp-18.txt) as Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-idr-aigp/ Technical Summary Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. Working Group Summary The working actively reviewed this draft considering the following: a) error handling with malformed packets or malformed transitive bits, b) placement of AIGP TLV in the draft; c) default setting for AIGP_SESSION on IBGP setting at SHOULD be "enabled" (AIGP_SESSION aids flagging the AIGP packets exiting the restricted environment to the wild), d) AIGP value is capped at maximum. This value cannot wrap, and any attempts to increase it past its maximum is treated as a malformed packet, and e) TLV formatting.. Document Quality This WG draft has been implemented by 3 vendors (including Juniper and Cisco), and seen deployment in ISPs. The debates around this draft have been resolved by the authors by the -14 draft. Shepherd did editorial pass on the draft, and the authors address the nits that shepherd found. Reviewers on the list were interested and complete in their review. The reviewers on the IDR list included long-time experts, newer implementers, deployment and research. While additional review is always good, this was a good review. IPR LC was done based on two disclosures from cisco: id #1159, #1160. No concerns were raised. Reviews done: Early OPS-IDR review by Ron Bonica resulted in several changes, and Ron Bonica approving the document. An Early IANA Review also resulted in changes. No comments were received from an early request for a Routing Directorate review. No MIB Doctor review is relevant for this review outside an OPS-DIR review. Personnel Shepherd: Susan Hares (WG chair) WG chairs: John Scudder and Susan Hares AD: Alia Atlas From nobody Tue May 20 13:42:13 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94CC1A0797 for ; Tue, 20 May 2014 13:42:11 -0700 (PDT) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSbV9lsvwVBI for ; Tue, 20 May 2014 13:42:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20711A07A0 for ; Tue, 20 May 2014 13:42:09 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.944.11; Tue, 20 May 2014 20:42:07 +0000 Received: from BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) by BLUPR05MB722.namprd05.prod.outlook.com ([10.141.207.150]) with mapi id 15.00.0944.000; Tue, 20 May 2014 20:42:07 +0000 From: John Scudder To: Chris Hall Thread-Topic: [Idr] draft-ietf-idr-error-handling-09.txt Thread-Index: AQHPdGv3qwjR0s7ZxESaFZmiUJ5rKw== Date: Tue, 20 May 2014 20:42:07 +0000 Message-ID: <4B1EEC84-4F47-41A9-8E9C-3EF3FC2CAF06@juniper.net> References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <021101cf745a$d7fa2f90$87ee8eb0$@highwayman.com> In-Reply-To: <021101cf745a$d7fa2f90$87ee8eb0$@highwayman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [208.54.35.189] x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(164054003)(24454002)(189002)(199002)(377454003)(74662001)(20776003)(64706001)(80022001)(31966008)(2656002)(21056001)(19580405001)(83716003)(66066001)(79102001)(19580395003)(83322001)(74502001)(36756003)(87936001)(33656002)(101416001)(46102001)(77096999)(82746002)(81342001)(99396002)(76482001)(92566001)(4396001)(54356999)(86362001)(83072002)(76176999)(50986999)(77982001)(81542001)(99286001)(85852003)(92726001)(42262001)(21314002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:BLUPR05MB722.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/sSUsfQFrMnC6_IhHdNpId257bkA Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:42:12 -0000 On May 20, 2014, at 2:39 PM, Chris Hall wrote: >=20 > John G. Scudder wrote (on Mon 19-May-2014 at 20:52 +0100): > ... >> - Note that when MP-BGP is in use, NEXT_HOP is discretionary. >> - Better text for NLRI section (thanks to Ondrej). >> - Fix typos. >>=20 >> With luck, we are spiraling in to a final version. >=20 > The requirement to put MP_xxx_NLRI as the first attribute appears to > have gone walk-about ? Oops! Thanks, will fix.=20 > So... treat-as-withdraw is to be applied to whatever (valid) NLRI the > receiver manages to find. If there are lost-NLRI, tant pis, go ahead > and do an "incomplete" treat-as-withdraw. >=20 > If no NLRI whatsoever can be found, then the receiver SHALL > treat-as-withdraw an empty set of NLRI. Yes ? >=20 > I accept that the receiver cannot do anything about lost-NLRI, not > least because (in the general case) it cannot tell whether there are > any ! >=20 > However, unless somebody knows better, it appears that existing > implementations currently: >=20 > * send at most 2 sets of NLRI in an UPDATE >=20 > * never mix MP_xx_NLRI attributes with non-empty > Withdrawn Routes or NLRI fields. >=20 > * send an MP_UNREACH_NLRI as the first (and > possibly only) attribute. >=20 > This does not change what the receiver can do... >=20 > ... but given that the likelihood of lost-NLRI is (in practice) > effectively zero, one can ignore the impact of "incomplete" > treat-as-withdraw (whatever that might be). >=20 > This seems to me worth covering in the draft... unless the impact of > "incomplete" treat-as-withdraw is deemed negligible -- in which case > it seems to me *that* would be worth covering too. Let me ask you much the same question I asked Deniz. That is: what, if anyt= hing, would you expect an implementor to do differently as a result of the = proposed text?=20 (That's not to say "no", mind you.) --John= From nobody Tue May 20 15:38:02 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1161A01EB for ; Tue, 20 May 2014 15:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEJdJkXGd_Py for ; Tue, 20 May 2014 15:37:58 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167981A03FF for ; Tue, 20 May 2014 15:37:55 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so1199173wgh.20 for ; Tue, 20 May 2014 15:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=EyfMqgnrfiMpONtgeBx3z5MIfy/Jbplp54Epu7rxvyg=; b=GJS2jOUFMCTWXNlj+TwSOF6CIvkiIlU4fC2fl5uyJ3hnVaBy7yB8q24gO7dd1MO1dW gFGdy7tNgJQiD79GKVUX3TD0VJ4QC6wJpSUVoDCVjN8yiljbjc3sV5Nhuu2+cDQxlbze wPWv/SWzWLxEGP0TNK6gB8k6qBB6MacN8UcfXi33aTOap6YK1DGh63vmFpiwClLNibum qQUJiPiOeVly8l8TLVBAB6HvYT+hmrs/njLEGXUC20ZQyl80BvpxVOfDIm2feQwvg1RJ ywXwbBFj+/ROlliIxYmp8qesoyycNRF8LD9FIofXfFXqOcZDfmsQw7YHbYLsqtyeyJc6 A5Fg== MIME-Version: 1.0 X-Received: by 10.180.100.41 with SMTP id ev9mr6870422wib.22.1400625474420; Tue, 20 May 2014 15:37:54 -0700 (PDT) Received: by 10.217.138.136 with HTTP; Tue, 20 May 2014 15:37:54 -0700 (PDT) Date: Tue, 20 May 2014 18:37:54 -0400 Message-ID: From: Alia Atlas To: draft-ietf-idr-bgp-enhanced-route-refresh@tools.ietf.org, "idr-chairs@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/8fuaAaxlf7wyd1mB4gbeu1hxrSs Cc: "idr@ietf. org" , idr-ads@tools.ietf.org Subject: [Idr] AD review of draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 22:38:00 -0000 As part of my routine evaluation of drafts before progressing them to IETF Last Call, I do a review. This draft is very clearly written and I have only a couple comments. Please do respond and update the draft - but I am also starting the IETF Last Call in parallel with the discussion. An updated version should be made available before June 5 or I will have to remove it from the IESG telechat scheduled for May 12. Comments: a) The draft should update RFC2918, given that it is redefining the "Reserved" field of the ROUTE-REFRESH message. b) I see that all 8 bits of the RESERVED field are being used for this purpose. Is there a reason to do so, given that only 3 values have a planned use? I know that there are existing implementations and I don't have another plan for those values - just general conservation. (Imagine wanting to do the same procedure but for a more limited scope of routes.) Thanks, Alia From nobody Tue May 20 15:45:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D961A03AB; Tue, 20 May 2014 15:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk-x1TSY-pQQ; Tue, 20 May 2014 15:45:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D881A03F0; Tue, 20 May 2014 15:45:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140520224536.2693.66939.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 15:45:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/3AYzuJFKWk8lhrwfz9_f8YjHDow Cc: idr@ietf.org Subject: [Idr] Last Call: (Enhanced Route Refresh Capability for BGP-4) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 22:45:44 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Enhanced Route Refresh Capability for BGP-4' as Proposed Standard 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 2014-06-03. 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 In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP RIB inconsistencies in a non-disruptive manner. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue May 20 19:55:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF24B1A0452; Tue, 20 May 2014 19:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk_ABo2TMB5J; Tue, 20 May 2014 19:55:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BD41A0443; Tue, 20 May 2014 19:55:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140521025534.26954.41151.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 19:55:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/9tLFTSZX_K6S5KuGsl0x5DZMCDU Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-07.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 02:55:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Reservation of Last Autonomous System (AS) Numbers Authors : Jeffrey Haas Jon Mitchell Filename : draft-ietf-idr-last-as-reservation-07.txt Pages : 4 Date : 2014-05-20 Abstract: This document reserves two Autonomous System numbers (ASNs) at the end of the 16 bit and 32 bit ranges, described in this document as "Last ASNs" and provides guidance to implementers and operators on their use. This document updates section 10 of RFC 1930. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-last-as-reservation-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 21 04:59:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BBA1A0538 for ; Wed, 21 May 2014 04:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NAr17Lv7ygc for ; Wed, 21 May 2014 04:59:29 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B64901A0314 for ; Wed, 21 May 2014 04:59:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 032A5C27E; Wed, 21 May 2014 07:59:28 -0400 (EDT) Date: Wed, 21 May 2014 07:59:28 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20140521115928.GB5675@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/gfISKDRTjQkh9MytYhYzCH5ilII Cc: draft-ietf-idr-bgp-enhanced-route-refresh@tools.ietf.org, "idr@ietf. org" , "idr-chairs@tools.ietf.org" , idr-ads@tools.ietf.org Subject: Re: [Idr] AD review of draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 11:59:31 -0000 Alia, (Clearly not speaking for the authors...) On Tue, May 20, 2014 at 06:37:54PM -0400, Alia Atlas wrote: > b) I see that all 8 bits of the RESERVED field are being used for this > purpose. Is there a reason to do so, given that only 3 values have a > planned use? I know that there are existing implementations and I > don't have another plan for those values - just general conservation. > (Imagine wanting to do the same procedure but for a more limited scope > of routes.) It seems to me that this is mostly turning the reserved field into the "sub-types" field (sec 2.2). While I don't foresee the likelihood of too much new work being done in here, would the right fix be to create an IANA registry for that field? -- Jeff From nobody Wed May 21 05:37:13 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CDB1A0669 for ; Wed, 21 May 2014 05:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQljep4eAJc5 for ; Wed, 21 May 2014 05:37:07 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B187F1A05C3 for ; Wed, 21 May 2014 05:36:49 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Wn5lE-0000Pd-2r for idr@ietf.org; Wed, 21 May 2014 12:36:44 +0000 From: "Chris Hall" To: "'idr@ietf. org'" References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <021101cf745a$d7fa2f90$87ee8eb0$@highwayman.com> <4B1EEC84-4F47-41A9-8E9C-3EF3FC2CAF06@juniper.net> In-Reply-To: <4B1EEC84-4F47-41A9-8E9C-3EF3FC2CAF06@juniper.net> Date: Wed, 21 May 2014 13:36:38 +0100 Organization: Highwayman Message-ID: <027c01cf74f1$5272a860$f757f920$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHq8GuwBYAROfMVxoWKkdFU2NUYygIe4lDJAkZBa1UCWfhe5Zrd/3dQ Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/YsXA5r4mYTcUP8FVeL3OQ185TOA Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 12:37:08 -0000 John Scudder wrote (on Tue 20-May-2014 at 21:42 +0100): > On May 20, 2014, at 2:39 PM, Chris Hall wrote: .... > > However, unless somebody knows better, it appears that existing > > implementations currently: > > > > * send at most 2 sets of NLRI in an UPDATE > > > > * never mix MP_xx_NLRI attributes with non-empty > > Withdrawn Routes or NLRI fields. > > > > * send an MP_UNREACH_NLRI as the first (and > > possibly only) attribute. ... > Let me ask you much the same question I asked Deniz. That is: what, > if anything, would you expect an implementor to do differently as a > result of the proposed text? Not quite answering the question directly... let me put the case ('A') of an UPDATE message in which the receiver finds: Withdrawn Routes field -- empty Attributes: ORIGIN -- some valid origin .... ) other valid stuff... .... ) ...but NOT MP_xx_NLRI -- attributes overrun NLRI field -- empty ...ie. the receiver can find no NLRI, but there is every reason to believe some were sent. For obvious reasons, many implementations place MP_REACH_NLRI after all other attributes, so this is a pretty obvious case. AFAICS this is not explicitly covered in the draft, so I ask: (1) what should the receiver do ? (a) "treat-as-withdraw" ? or (b) "session-reset" ? (2) what is the rationale for the choice ? Not wishing to sway the jury here, but if the receiver had found an MP_REACH_NLRI which was not "perfectly-formed", then that would be "session-reset". And then there is the similar case ('B') of: Withdrawn Routes field -- empty Attributes: MP_UNREACH_NLRI -- "perfectly formed" ORIGIN -- some valid origin .... ) other valid stuff... .... ) ...but NOT MP_REACH_NLRI -- attributes overrun NLRI field -- empty What should the receiver do now, and why ? Chris From nobody Wed May 21 05:47:58 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679781A0360 for ; Wed, 21 May 2014 05:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUaeBikUQ4t9 for ; Wed, 21 May 2014 05:47:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2661A0344 for ; Wed, 21 May 2014 05:47:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8957CC091; Wed, 21 May 2014 08:47:53 -0400 (EDT) Date: Wed, 21 May 2014 08:47:53 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20140521124753.GC5675@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/4-WerELzBcAWCVpuIoCrDpldqoA Subject: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 12:47:55 -0000 IDR, RFC 4684 (Constrained Route Target Distribution) is obviously a useful tool. At work, we've run into an interesting case and I thought I'd share some of the internal debate on it. In RFC 6037 ("draft-rosen" multicast VPNs), the MDT SAFI has the following documentation in section 4.4: : When a PE distributes this NLRI via BGP, it may include a Route : Target (RT) Extended Communities attribute. This RT must be an : "Import RT" [RFC4364] of each VRF in the MD. The ordinary BGP : distribution procedures used by [RFC4364] will then ensure that each : PE learns the MDT-SAFI "address" of each of the other PEs in the MD, : and that the learned MDT-SAFI addresses get associated with the right : VRFs. RFC 4684's procedure says in section 6: : A VPN NLRI route should be advertised to a peer that participates in : the exchange of Route Target membership information if that peer has : advertised either the default Route Target membership NLRI or a Route : Target membership NLRI containing any of the targets contained in the : extended communities attribute of the VPN route in question. Quite frankly, we have a bug in that MDT's are not getting propagated when RT-C is in use because we're treating it as a "VPN NLRI". Simple fix, but one that leaves me wondering if the issue is more general - and perhaps worthy of an errata for RFC 4684. For the MDT case, one can make the argument that since it may be distributed without RTs, it's only a "VPN NLRI" if it contains RTs. The broader question I'd put to the working group is whether any NLRI not having RTs isn't really a "VPN NLRI" for purposes of RT-C filtering. This really leaves two simple schools of thought: 1. No RT, no RT-C filtering. 2. MDT SAFI is an odd-ball case, just deal with that. (And perhaps warn in future BGP documents that may use RT-C about how to deal with no RTs when they're optional.) -- Jeff From nobody Wed May 21 05:51:12 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8CC1A0639 for ; Wed, 21 May 2014 05:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDMyELerzRZP for ; Wed, 21 May 2014 05:51:07 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4558D1A05C3 for ; Wed, 21 May 2014 05:51:07 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id f73so1606722yha.0 for ; Wed, 21 May 2014 05:51:06 -0700 (PDT) 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=z+99TIf5EgY9JZfOZi6b2TRHSYDlFhlpLcW2lEw4kF8=; b=CtY6moXmh0qHzxf5vvpc7ZYq3Zv2JGeZ/+DW7ya3XZjjtKdPUDPZEPtqes2jjN5YTa qcDKpVf9fMgUKQGeYrQx3bqJ5/5i5v2P9SUsfcSFk8SOVPBWBFFnvVn5ywuSAI4Y1s9Y P9OAxG5OM3xoW8XcKhJ/KJR2QNyPJG8Nz7Lm0jmcGYbVDYyRi7jzORX4+X47v7KT3R6E 40CXEaPryslziMJEik49Xq1sSB5OvimBJTv+ADXsdL84e4INSoUavvgCCQ8VUTxh8m1D DOug5Y9zNTMEKI/JNBJcvKzGS5SfH075hCZ7JhnrX2nFpNfr4T4MAYrC8s9YIlsmilnD W/2Q== MIME-Version: 1.0 X-Received: by 10.236.199.78 with SMTP id w54mr26636332yhn.139.1400676666028; Wed, 21 May 2014 05:51:06 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Wed, 21 May 2014 05:51:05 -0700 (PDT) In-Reply-To: <20140521115928.GB5675@pfrc> References: <20140521115928.GB5675@pfrc> Date: Wed, 21 May 2014 08:51:05 -0400 Message-ID: From: Alia Atlas To: Jeffrey Haas Content-Type: multipart/alternative; boundary=089e0158c41c1fb82f04f9e873cb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/gvoBHbCgNGPq_bEimoZ74YScZpI Cc: draft-ietf-idr-bgp-enhanced-route-refresh , "idr@ietf. org" , "idr-chairs@tools.ietf.org" , idr-ads@tools.ietf.org Subject: Re: [Idr] AD review of draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 12:51:08 -0000 --089e0158c41c1fb82f04f9e873cb Content-Type: text/plain; charset=UTF-8 Jeff, The draft has a registry for this already. I was thinking of any need for future bits. If it's been thought about and deemed not needed, that is sufficient. Alia On Wed, May 21, 2014 at 7:59 AM, Jeffrey Haas wrote: > Alia, > > (Clearly not speaking for the authors...) > > On Tue, May 20, 2014 at 06:37:54PM -0400, Alia Atlas wrote: > > b) I see that all 8 bits of the RESERVED field are being used for this > > purpose. Is there a reason to do so, given that only 3 values have a > > planned use? I know that there are existing implementations and I > > don't have another plan for those values - just general conservation. > > (Imagine wanting to do the same procedure but for a more limited scope > > of routes.) > > It seems to me that this is mostly turning the reserved field into the > "sub-types" field (sec 2.2). While I don't foresee the likelihood of too > much new work being done in here, would the right fix be to create an IANA > registry for that field? > > -- Jeff > --089e0158c41c1fb82f04f9e873cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

The draft has a registry for this= already. =C2=A0I was thinking of any need for future bits.
If it= 's been thought about and deemed not needed, that is sufficient.
<= div>
Alia


On Wed, May 21, 2014 at 7:59 AM, Jeffrey Haas <jhaas@pfrc= .org> wrote:
Alia,

(Clearly not speaking for the authors...)

On Tue, May 20, 2014 at 06:37:54PM -0400, Alia Atlas wrote:
> b) I see that all 8 bits of the RESERVED field are being used for this=
> purpose. =C2=A0Is there a reason to do so, given that only 3 values ha= ve a
> planned use? =C2=A0 I know that there are existing implementations and= I
> don't have another plan for those values - just general conservati= on.
> (Imagine wanting to do the same procedure but for a more limited scope=
> of routes.)

It seems to me that this is mostly turning the reserved field into th= e
"sub-types" field (sec 2.2). =C2=A0While I don't foresee the = likelihood of too
much new work being done in here, would the right fix be to create an IANA<= br> registry for that field?

-- Jeff

--089e0158c41c1fb82f04f9e873cb-- From nobody Wed May 21 05:56:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738EB1A0360 for ; Wed, 21 May 2014 05:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBGRAo2UXcue for ; Wed, 21 May 2014 05:56:30 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 86B471A0358 for ; Wed, 21 May 2014 05:56:30 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 77A73C26A; Wed, 21 May 2014 08:56:29 -0400 (EDT) Date: Wed, 21 May 2014 08:56:29 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20140521125629.GD5675@pfrc> References: <20140521115928.GB5675@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/__D6R5uvyoQ8GsKhi0w48H62Hgg Cc: draft-ietf-idr-bgp-enhanced-route-refresh , "idr-chairs@tools.ietf.org" , idr-ads@tools.ietf.org, "idr@ietf. org" Subject: Re: [Idr] AD review of draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 12:56:31 -0000 On Wed, May 21, 2014 at 08:51:05AM -0400, Alia Atlas wrote: > The draft has a registry for this already. And of course now I notice that Google had taken me to -02. :-P > I was thinking of any need for future bits. If it's been thought about > and deemed not needed, that is sufficient. I don't believe such discussion in that context has happened. The scheme (in -06) basically would make it unlikely to carve up the numbers into bitfields at a later date. If we got to the point where that was truly necessary, I suspect someone would just allocate a new message type and make a next-generation route refresh. We're not exactly going through BGP message code points very quickly. -- Jeff From nobody Wed May 21 07:25:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7491A06B7 for ; Wed, 21 May 2014 07:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhcbJXM027Lt for ; Wed, 21 May 2014 07:25:01 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8DCB1A03DD for ; Wed, 21 May 2014 07:25:00 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-d5-537c65109ffd Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 96.57.11744.0156C735; Wed, 21 May 2014 10:34:24 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Wed, 21 May 2014 10:24:57 -0400 From: Jakob Heitz To: Chris Hall Thread-Topic: [Idr] draft-ietf-idr-error-handling-09.txt Thread-Index: AQHPc6nYqVW2LHUOZUe2HIkfo5d8L5tKEWMAgAAiRYCAAQqwAP//2zZ1 Date: Wed, 21 May 2014 14:24:57 +0000 Message-ID: References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <021101cf745a$d7fa2f90$87ee8eb0$@highwayman.com> <4B1EEC84-4F47-41A9-8E9C-3EF3FC2CAF06@juniper.net>, <027c01cf74f1$5272a860$f757f920$@highwayman.com> In-Reply-To: <027c01cf74f1$5272a860$f757f920$@highwayman.com> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXRPoK5Aak2wwdFT2hbvf21jtnh1+xmT A5PH8aO7mD2WLPnJFMAUxWWTkpqTWZZapG+XwJWxtbWVtWAtW8WlbvcGxrUsXYycHBICJhI/ f/SxQthiEhfurWfrYuTiEBI4yihx4fs8VghnOaPEnnP9jCBVbAI6Et+udzGD2CICWhKrN8xi A7GZBZQktk09yA5iCwuYS3z91sACUWMhcXhGNxOE7Sbx+MMSsHoWAVWJSdtfgtXwCthLPN07 nwViWT+TxMWT18ESnAK2EtNa54MtYwQ67/upNUwQy8Qlbj2ZzwRxtoDEkj3nmSFsUYmXj/+x QtToSCzY/QnqOG2JZQtfM0MsE5Q4OfMJywRG0VlIRs1C0jILScssJC0LGFlWMXKUFqeW5aYb GW5iBMbDMQk2xx2MCz5ZHmIU4GBU4uFdoF4dLMSaWFZcmXuIUZqDRUmcd8+1qmAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjGb/j30xlzWQ8/j61rjoxtJFDidetU/eYJ4kGasae33J0XhL Xb4nrr7LZTgPCvHxKDKusE48Lr3q4bctW28lb03S9T13wYyzd3XAncen2oS+i5wsi3ZKL+u+ XvX9mdMM3blfmVX1lr81r3KPlb/0Yb/g+fS6pVsk887ebTl+8//F3fLzjuy6kK/EUpyRaKjF XFScCAD7XVDcaAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/idr/s5qo4a8WRNSqrMF76bYhGRlTgH4 Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 14:25:02 -0000 Good one. What SHOULD a receiver do with this? Withdrawn Routes field -- empty Attributes: MP_UNREACH_NLRI -- "perfectly formed" .... ) valid attributes ...=20 .... ) ...but NOT MP_REACH_NLRI NLRI field -- empty -- Jakob Heitz. > On May 21, 2014, at 5:37 AM, "Chris Hall" wro= te: >=20 > And then there is the similar case ('B') of: >=20 > Withdrawn Routes field -- empty > Attributes: MP_UNREACH_NLRI -- "perfectly formed" > ORIGIN -- some valid origin > .... ) other valid stuff...=20 > .... ) ...but NOT MP_REACH_NLRI > -- attributes overrun > NLRI field -- empty >=20 > What should the receiver do now, and why ? >=20 > Chris >=20 From nobody Wed May 21 08:07:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3218B1A0691 for ; Wed, 21 May 2014 08:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDOVgMoGy4Hw for ; Wed, 21 May 2014 08:07:39 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683051A03D0 for ; Wed, 21 May 2014 08:07:36 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-eb-537c717a8a30 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EF.2A.27529.A717C735; Wed, 21 May 2014 11:27:22 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Wed, 21 May 2014 11:07:33 -0400 From: Jakob Heitz To: Jeffrey Haas Thread-Topic: [Idr] RFC 4684 pedantry - routes with no Route Target Thread-Index: AQHPdPLoJ6JdM6V8MU6PYk7OV5XkbZtLIuHV Date: Wed, 21 May 2014 15:07:32 +0000 Message-ID: <3608BE2D-06C9-4D9A-B4D6-C297605D67E7@ericsson.com> References: <20140521124753.GC5675@pfrc> In-Reply-To: <20140521124753.GC5675@pfrc> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXSPt25VYU2wwfZZFhavbj9jsth/8C2r A5PHkiU/mTwu925lDWCK4rJJSc3JLEst0rdL4Mo48/UWY0GrSMXyCY2sDYyX+bsYOTgkBEwk Zu7T62LkBDLFJC7cW8/WxcjFISRwlFHizf71rBDOckaJjvk7mECq2AR0JL5d72IGsUUEFCXm /+9kA7GZgeyLfzvAaoQFnCSWdJ1ihKhxlvh7uI8FwjaSmHX9ECuIzSKgKjHl8QV2EJtXwF7i 6sP/YHEhAQ2JEz/2gtVzCmhK7LywGmwmI9B130+tYYLYJS5x68l8JoirBSSW7DnPDGGLSrx8 /I8VokZHYsHuT1C3aUssW/iaGWKXoMTJmU9YJjCKzkIyahaSlllIWmYhaVnAyLKKkaO0OLUs N93IYBMjMBqOSbDp7mDc89LyEKMAB6MSD6/CjOpgIdbEsuLK3EOM0hwsSuK82jergoUE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwptedmGq98uv394lvLgQs4b7Va9jXeMC585ePEQP/dtWb UZk1E6ZP0/OYG3/s7Atm86Nzlurl7RJ4efJepnJe5af7xpV2sy7J+O5ofblCn9dUx6Npf+9F jZn2+9WfBl8+v/mvDZd7LPOT09wzq3/NfvJ89e+kYzNjEq/OzJlwUSQ3PZ479gHvLSWW4oxE Qy3mouJEAFFOHchnAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/idr/-Dj3mdgV2_RJoRcX4OJ-wBCYhwE Cc: "idr@ietf.org" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:07:48 -0000 I am for 1. No RT, no RT-C filtering. Moreover, for ANY address family (including RT-C) if an UPDATE includes an = RT, then RT-C filter it. No special exceptions if an RT-C UPDATE contains t= he same RT in the NLRI and the attribute field. -- Jakob Heitz. > On May 21, 2014, at 5:48 AM, "Jeffrey Haas" wrote: >=20 > IDR, >=20 > RFC 4684 (Constrained Route Target Distribution) is obviously a useful to= ol. > At work, we've run into an interesting case and I thought I'd share some = of > the internal debate on it. >=20 > In RFC 6037 ("draft-rosen" multicast VPNs), the MDT SAFI has the followin= g > documentation in section 4.4: >=20 > : When a PE distributes this NLRI via BGP, it may include a Route > : Target (RT) Extended Communities attribute. This RT must be an > : "Import RT" [RFC4364] of each VRF in the MD. The ordinary BGP > : distribution procedures used by [RFC4364] will then ensure that each > : PE learns the MDT-SAFI "address" of each of the other PEs in the MD, > : and that the learned MDT-SAFI addresses get associated with the right > : VRFs. >=20 > RFC 4684's procedure says in section 6: > : A VPN NLRI route should be advertised to a peer that participates in > : the exchange of Route Target membership information if that peer has > : advertised either the default Route Target membership NLRI or a Route > : Target membership NLRI containing any of the targets contained in the > : extended communities attribute of the VPN route in question. >=20 > Quite frankly, we have a bug in that MDT's are not getting propagated whe= n > RT-C is in use because we're treating it as a "VPN NLRI". Simple fix, bu= t > one that leaves me wondering if the issue is more general - and perhaps > worthy of an errata for RFC 4684. >=20 > For the MDT case, one can make the argument that since it may be distribu= ted > without RTs, it's only a "VPN NLRI" if it contains RTs. >=20 > The broader question I'd put to the working group is whether any NLRI not > having RTs isn't really a "VPN NLRI" for purposes of RT-C filtering. Thi= s > really leaves two simple schools of thought: > 1. No RT, no RT-C filtering. > 2. MDT SAFI is an odd-ball case, just deal with that. (And perhaps warn = in > future BGP documents that may use RT-C about how to deal with no RTs when > they're optional.) >=20 > -- Jeff >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 21 08:22:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8460B1A087D for ; Wed, 21 May 2014 08:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAb9xLXjYtNb for ; Wed, 21 May 2014 08:21:50 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC601A06D6 for ; Wed, 21 May 2014 08:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2670; q=dns/txt; s=iport; t=1400685706; x=1401895306; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=zUI+BY/fgBPzs67K//H16c2EeLjYVcQ6XZaCCsIYtgw=; b=bBoRjNx65wHjiKQNIVMHORir/iYCbjNtViFcDbWjAJXygOi7v8Q2JWsR jac6yf6LKUrYSPnAtCSgrIVtaXspOGFSa9vsA3O1+H7DoVQxkYpXapULT gJ0WSsLyaGIQ7rCxJ8g7Mp0M1mba+2c7WqrO0YnuCI17PqaRLApfb4hZ7 k=; X-IronPort-AV: E=Sophos;i="4.98,880,1392163200"; d="scan'208";a="45883597" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 21 May 2014 15:21:45 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s4LFLj81017543; Wed, 21 May 2014 15:21:45 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id D258E75B; Wed, 21 May 2014 11:21:44 -0400 (EDT) From: Eric Rosen To: Jeffrey Haas In-reply-to: Your message of Wed, 21 May 2014 08:47:53 -0400. <20140521124753.GC5675@pfrc> Date: Wed, 21 May 2014 11:21:44 -0400 Message-ID: <8540.1400685704@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/n6L93JZ94otCE3VALGZFyRloMn4 Cc: idr@ietf.org Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:21:54 -0000 Jeff> In RFC 6037 ("draft-rosen" multicast VPNs), the MDT SAFI has the Jeff> following documentation in section 4.4: : When a PE distributes this NLRI via BGP, it may include a Route : Target (RT) Extended Communities attribute. This RT must be an : "Import RT" [RFC4364] of each VRF in the MD. The ordinary BGP : distribution procedures used by [RFC4364] will then ensure that each : PE learns the MDT-SAFI "address" of each of the other PEs in the MD, : and that the learned MDT-SAFI addresses get associated with the right : VRFs. The next paragraph though makes it clear (well, sort of) that the MDT-SAFI routes without RTs need to be distributed to all the PEs, and filtered as necessary by the PEs to which they are distributed. Jeff> RFC 4684's procedure says in section 6: : A VPN NLRI route should be advertised to a peer that participates in : the exchange of Route Target membership information if that peer has : advertised either the default Route Target membership NLRI or a Route : Target membership NLRI containing any of the targets contained in the : extended communities attribute of the VPN route in question. Jeff> Quite frankly, we have a bug in that MDT's are not getting propagated Jeff> when RT-C is in use because we're treating it as a "VPN NLRI". Yes, one might conclude that whoever decided to omit the RTs from MDT-SAFIs wasn't much concerned about the use of RT-C (or any other RT-based filtering mechanisms) to constrain the distribution of routes to or from intermediate nodes. Jeff> The broader question I'd put to the working group is whether any NLRI Jeff> not having RTs isn't really a "VPN NLRI" for purposes of RT-C Jeff> filtering I don't think RFC4684 really intends to restrict its applicability to "VPN routes". It does say in section 1: "This mechanism is applicable to any BGP NLRI that controls the distribution of routing information by using Route Targets". The problem arises because, on some NLRIs, the use of RTs is optional. What you're suggesting is that RT-C should never filter out routes that don't have any RTs. That does seem right. You may want to look at draft-zzhang-l3vpn-mvpn-global-table-mcast-02.txt, especially section 2.2 ("Route Targets"). In that draft, there are routes of the MCAST-VPN SAFI that may (optionally) carry RTs, and the intention is that it be possible to use RT-C to constrain the distribution of those routes, if (and only if) the routes carry RTs. However, those routes cannot really be said to be VPN routes, as they are used for controlling multicasts that do not occur in a VPN context. From nobody Wed May 21 08:52:35 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0571A0445 for ; Wed, 21 May 2014 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APwg-gzJ--_b for ; Wed, 21 May 2014 08:52:26 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5006F1A0738 for ; Wed, 21 May 2014 08:52:26 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 11478C26A; Wed, 21 May 2014 11:52:25 -0400 (EDT) Date: Wed, 21 May 2014 11:52:25 -0400 From: Jeffrey Haas To: Eric Rosen Message-ID: <20140521155225.GD9789@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8540.1400685704@erosen-lnx> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/nvlfeLEeyuL5L6gzYU2MbgVfQRQ Cc: idr@ietf.org Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:52:31 -0000 On Wed, May 21, 2014 at 11:21:44AM -0400, Eric Rosen wrote: > Jeff> The broader question I'd put to the working group is whether any NLRI > Jeff> not having RTs isn't really a "VPN NLRI" for purposes of RT-C > Jeff> filtering > > I don't think RFC4684 really intends to restrict its applicability to "VPN > routes". It does say in section 1: "This mechanism is applicable to any BGP > NLRI that controls the distribution of routing information by using Route > Targets". (And Jakob also raised the same point.) It should be noted that we leveraged the same thing for the draft-ietf-idr-mdcs proposal. :-) > The problem arises because, on some NLRIs, the use of RTs is > optional. What you're suggesting is that RT-C should never filter out > routes that don't have any RTs. That does seem right. I think that's 3 people that are in agreement. I'd like to leave the discussion open for a little bit to get additional consensus in the WG. Chairs, presuming that we do end up with that sort of behavioral consensus about no RT's, is an errata against RFC 4684 sufficient or would you want to see something more? -- Jeff From nobody Wed May 21 09:21:08 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEBC1A032F for ; Wed, 21 May 2014 09:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHwL4Ev-oyym for ; Wed, 21 May 2014 09:21:03 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EFD21A0723 for ; Wed, 21 May 2014 09:20:59 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id uy17so6428409igb.5 for ; Wed, 21 May 2014 09:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=V6q/zyIxTqC1zQfVtfm33vCjyJaW0ekiJglODz9IRrk=; b=E4ncFAIfxq6Xqi8tU4omR1yaZkqFdQ6SKFpDvN9CjMjL62/FWT3FeZTlqnVaHFLYjs L3hOMVgU6e0Suq/fJhi0UbwBiUWosbDcvL6kqpe5mXaHnMjzrcss2NfQnieBMToihPcD omcQRBvxIkzgRa/BFzpw2Ai/txR5+7yx3YvH2gozfd9TedUnn2veCjUyKJ5vSLYPQJHA mZ6GH4rNbtTe7ckDe5TExPmKf6hQ3/MEe5EIFhCsWboAZgdsvVwTQreCJpmnneNnZkOS ww884TwZN6mYVwrzCdKcIfQN7moiJhubUTBqS9dr4z8oBLuJujB6fHrLGm6gcxDqcTI1 iAuA== MIME-Version: 1.0 X-Received: by 10.50.13.67 with SMTP id f3mr15148105igc.9.1400689258199; Wed, 21 May 2014 09:20:58 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 21 May 2014 09:20:58 -0700 (PDT) In-Reply-To: <8540.1400685704@erosen-lnx> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> Date: Wed, 21 May 2014 18:20:58 +0200 X-Google-Sender-Auth: Z5jgThZCb-wtMp5WrdE-VlmhTU8 Message-ID: From: Robert Raszuk To: "erosen@cisco.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/uw1aq8-Au1mU0kuoVZhaHWglvKw Cc: idr wg Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:21:06 -0000 Hi Eric, > The problem arises because, on some NLRIs, the use of RTs is > optional. What you're suggesting is that RT-C should never filter out > routes that don't have any RTs. That does seem right. Well is it really ... ? Remember that RFC 4684 enforces for any SAFI it is enabled under no route exchange happens at all till intersecting RTs are received over RTC SAFI. That means that the spec is 180 degrees opposite to your above claim that routes with no RTs should be always exchanged. Cheers, R. On Wed, May 21, 2014 at 5:21 PM, Eric Rosen wrote: > Jeff> In RFC 6037 ("draft-rosen" multicast VPNs), the MDT SAFI has the > Jeff> following documentation in section 4.4: > > : When a PE distributes this NLRI via BGP, it may include a Route > : Target (RT) Extended Communities attribute. This RT must be an > : "Import RT" [RFC4364] of each VRF in the MD. The ordinary BGP > : distribution procedures used by [RFC4364] will then ensure that each > : PE learns the MDT-SAFI "address" of each of the other PEs in the MD, > : and that the learned MDT-SAFI addresses get associated with the right > : VRFs. > > The next paragraph though makes it clear (well, sort of) that the MDT-SAFI > routes without RTs need to be distributed to all the PEs, and filtered as > necessary by the PEs to which they are distributed. > > Jeff> RFC 4684's procedure says in section 6: > : A VPN NLRI route should be advertised to a peer that participates in > : the exchange of Route Target membership information if that peer has > : advertised either the default Route Target membership NLRI or a Route > : Target membership NLRI containing any of the targets contained in the > : extended communities attribute of the VPN route in question. > > Jeff> Quite frankly, we have a bug in that MDT's are not getting propagated > Jeff> when RT-C is in use because we're treating it as a "VPN NLRI". > > Yes, one might conclude that whoever decided to omit the RTs from MDT-SAFIs > wasn't much concerned about the use of RT-C (or any other RT-based filtering > mechanisms) to constrain the distribution of routes to or from intermediate > nodes. > > Jeff> The broader question I'd put to the working group is whether any NLRI > Jeff> not having RTs isn't really a "VPN NLRI" for purposes of RT-C > Jeff> filtering > > I don't think RFC4684 really intends to restrict its applicability to "VPN > routes". It does say in section 1: "This mechanism is applicable to any BGP > NLRI that controls the distribution of routing information by using Route > Targets". The problem arises because, on some NLRIs, the use of RTs is > optional. What you're suggesting is that RT-C should never filter out > routes that don't have any RTs. That does seem right. > > You may want to look at draft-zzhang-l3vpn-mvpn-global-table-mcast-02.txt, > especially section 2.2 ("Route Targets"). In that draft, there are routes > of the MCAST-VPN SAFI that may (optionally) carry RTs, and the intention is > that it be possible to use RT-C to constrain the distribution of those > routes, if (and only if) the routes carry RTs. However, those routes cannot > really be said to be VPN routes, as they are used for controlling multicasts > that do not occur in a VPN context. > > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 21 09:33:28 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20A1A03DD for ; Wed, 21 May 2014 09:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkLaluVC9MFs for ; Wed, 21 May 2014 09:33:26 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7701A0346 for ; Wed, 21 May 2014 09:33:26 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id c1so6428262igq.16 for ; Wed, 21 May 2014 09:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4U2QvPqfin3fvRED15OKUTNJ5LL9qc5G9uoRBgLkiZs=; b=mpW6ZJaT2JeWvHO5br2nFS7Ad9Ilb1PbswrAfCWzlb3d33rRWc/XFZ6X4lxlXSCCu7 gy1Y0ETrw4DCjHVEdB0FWVwWbBRDVfJLA+6+0QNFLT+rga0ri2j4IHFZw+30NnAE3kPU UvviPtZT7xnlmChOxWkPZWrv+K/szLmvY7eUfgzProuH4UfCJH65XCaqhgXrs41E+K9a Fofpf1XUQfYnw7YvDxEnyXk3yRJlxvIrhqZbN3Xynq2fEMmeRzCCe30OmDw4z18BeDBg Y2qvA8+3jiuvdQJ6xrx+9oDvWzIBRuNXNwNgcK6rwjmNPN7lThlsGJLZXD+jtEbm8LOd enzA== MIME-Version: 1.0 X-Received: by 10.50.43.225 with SMTP id z1mr14804397igl.29.1400690004975; Wed, 21 May 2014 09:33:24 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 21 May 2014 09:33:24 -0700 (PDT) In-Reply-To: References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> Date: Wed, 21 May 2014 18:33:24 +0200 X-Google-Sender-Auth: ibr58T_uXm0K8qhuk6agxN9OrHo Message-ID: From: Robert Raszuk To: "erosen@cisco.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/QIjX_esrK0Thi_dCsJNsPWNyylw Cc: idr wg Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:33:27 -0000 In the situations where protocol SAFI contains a mix (tagged and not tagged NLRIs with RTs) I would rather propose to amend the rfc to exchange default RT + specific RTs. That would potentially allow for reception of NLRIs with no RT attached + filtering of those against more specific RTs received which do carry RT ext community. Thoughts ? r. On Wed, May 21, 2014 at 6:20 PM, Robert Raszuk wrote: > Hi Eric, > >> The problem arises because, on some NLRIs, the use of RTs is >> optional. What you're suggesting is that RT-C should never filter out >> routes that don't have any RTs. That does seem right. > > Well is it really ... ? > > Remember that RFC 4684 enforces for any SAFI it is enabled under no > route exchange happens at all till intersecting RTs are received over > RTC SAFI. > > That means that the spec is 180 degrees opposite to your above claim > that routes with no RTs should be always exchanged. > > Cheers, > R. > > > On Wed, May 21, 2014 at 5:21 PM, Eric Rosen wrote: >> Jeff> In RFC 6037 ("draft-rosen" multicast VPNs), the MDT SAFI has the >> Jeff> following documentation in section 4.4: >> >> : When a PE distributes this NLRI via BGP, it may include a Route >> : Target (RT) Extended Communities attribute. This RT must be an >> : "Import RT" [RFC4364] of each VRF in the MD. The ordinary BGP >> : distribution procedures used by [RFC4364] will then ensure that each >> : PE learns the MDT-SAFI "address" of each of the other PEs in the MD, >> : and that the learned MDT-SAFI addresses get associated with the right >> : VRFs. >> >> The next paragraph though makes it clear (well, sort of) that the MDT-SAFI >> routes without RTs need to be distributed to all the PEs, and filtered as >> necessary by the PEs to which they are distributed. >> >> Jeff> RFC 4684's procedure says in section 6: >> : A VPN NLRI route should be advertised to a peer that participates in >> : the exchange of Route Target membership information if that peer has >> : advertised either the default Route Target membership NLRI or a Route >> : Target membership NLRI containing any of the targets contained in the >> : extended communities attribute of the VPN route in question. >> >> Jeff> Quite frankly, we have a bug in that MDT's are not getting propagated >> Jeff> when RT-C is in use because we're treating it as a "VPN NLRI". >> >> Yes, one might conclude that whoever decided to omit the RTs from MDT-SAFIs >> wasn't much concerned about the use of RT-C (or any other RT-based filtering >> mechanisms) to constrain the distribution of routes to or from intermediate >> nodes. >> >> Jeff> The broader question I'd put to the working group is whether any NLRI >> Jeff> not having RTs isn't really a "VPN NLRI" for purposes of RT-C >> Jeff> filtering >> >> I don't think RFC4684 really intends to restrict its applicability to "VPN >> routes". It does say in section 1: "This mechanism is applicable to any BGP >> NLRI that controls the distribution of routing information by using Route >> Targets". The problem arises because, on some NLRIs, the use of RTs is >> optional. What you're suggesting is that RT-C should never filter out >> routes that don't have any RTs. That does seem right. >> >> You may want to look at draft-zzhang-l3vpn-mvpn-global-table-mcast-02.txt, >> especially section 2.2 ("Route Targets"). In that draft, there are routes >> of the MCAST-VPN SAFI that may (optionally) carry RTs, and the intention is >> that it be possible to use RT-C to constrain the distribution of those >> routes, if (and only if) the routes carry RTs. However, those routes cannot >> really be said to be VPN routes, as they are used for controlling multicasts >> that do not occur in a VPN context. >> >> >> >> >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 21 09:36:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A411A0481 for ; Wed, 21 May 2014 09:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcJCstBFTxEN for ; Wed, 21 May 2014 09:36:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 45BE91A03DD for ; Wed, 21 May 2014 09:36:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 66389C26A; Wed, 21 May 2014 12:36:21 -0400 (EDT) Date: Wed, 21 May 2014 12:36:21 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140521163621.GF9789@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jVOKksp5Txwil6ertW_8IAisL0U Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:36:23 -0000 Robert, On Wed, May 21, 2014 at 06:20:58PM +0200, Robert Raszuk wrote: > Remember that RFC 4684 enforces for any SAFI it is enabled under no > route exchange happens at all till intersecting RTs are received over > RTC SAFI. > > That means that the spec is 180 degrees opposite to your above claim > that routes with no RTs should be always exchanged. While a complicating factor certainly, we'd still end up sending along those routes after either end-of-rib for RT-C or the timeout. (Presuming the implementation follows the SHOULD.) So, while it causes potential delay to the subset of the routes carrying no RT, presumably they're in the same family because some of the routes will have an RT and want to benefit from the feature. -- Jeff From nobody Wed May 21 09:37:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C901A0564 for ; Wed, 21 May 2014 09:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpI-HtfkwFze for ; Wed, 21 May 2014 09:37:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 24F071A0481 for ; Wed, 21 May 2014 09:37:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 59C41C26A; Wed, 21 May 2014 12:37:42 -0400 (EDT) Date: Wed, 21 May 2014 12:37:42 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140521163742.GG9789@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Hd7ZuZvWWaTGDG0VjLpznzVsz2Y Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:37:44 -0000 On Wed, May 21, 2014 at 06:33:24PM +0200, Robert Raszuk wrote: > In the situations where protocol SAFI contains a mix (tagged and not > tagged NLRIs with RTs) I would rather propose to amend the rfc to > exchange default RT + specific RTs. That would potentially allow for > reception of NLRIs with no RT attached + filtering of those against > more specific RTs received which do carry RT ext community. Default RT-C effectively negates the usefulness of the feature. I wouldn't recommend this. -- Jeff From nobody Wed May 21 09:38:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05871A06DC for ; Wed, 21 May 2014 09:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CICkislSx7PP for ; Wed, 21 May 2014 09:38:51 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3136B1A0690 for ; Wed, 21 May 2014 09:38:51 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id at1so2263095iec.29 for ; Wed, 21 May 2014 09:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yKjf0GjxPhPjsISjGPrjZMdtbWkyaawnMAFIQiPl3+U=; b=ea+HKfbz9MKpmMJm6zBDWyUVDStvHOli2p5hxidFIZu/JqLhggr6ak5HlRFSpbcl4P C9U7gHYSw1+65fICcXQYy6IP5G8lEIoLyBykXOnn5tDwY772p9YJpCtcfgd2YigIslut /Lr96HgxQJJgv3JliiPOMg/mgXJrU9SswutsbKldnCYYzlmvfox7C2O5oIoNsxf9Qj+t lZHghy2r/yZwoVPTU+GzPigTMpN5IXK0yWkn1rWbE/sgAo112DrF5s9i7NogfBpV+ILM qYlTWH4dnKt/gEjC+cscSWLIaTb23/yIkdVejWXQ7Alb68dilHH7PcW6YthhXh9buDDE tbrg== MIME-Version: 1.0 X-Received: by 10.50.43.225 with SMTP id z1mr14845323igl.29.1400690329865; Wed, 21 May 2014 09:38:49 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 21 May 2014 09:38:49 -0700 (PDT) In-Reply-To: <20140521163621.GF9789@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163621.GF9789@pfrc> Date: Wed, 21 May 2014 18:38:49 +0200 X-Google-Sender-Auth: wxjk-yfJ0UKv1XLaKI4TuE_XRvU Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hjHNBXn1szIg3mv0Fg7GCWM0f7A Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:38:52 -0000 > While a complicating factor certainly, we'd still end up sending along those > routes after either end-of-rib for RT-C or the timeout. (Presuming the > implementation follows the SHOULD.) After timeout yes, but not after valid set of RTC RT NLRIs followed by EOR. .. I would not expect to see those in the latter case. r. > So, while it causes potential delay to the subset of the routes carrying no > RT, presumably they're in the same family because some of the routes will > have an RT and want to benefit from the feature. > > -- Jeff From nobody Wed May 21 09:40:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034361A045E for ; Wed, 21 May 2014 09:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq3W41fYY_SM for ; Wed, 21 May 2014 09:40:55 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126491A0346 for ; Wed, 21 May 2014 09:40:55 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id as1so2268231iec.27 for ; Wed, 21 May 2014 09:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CZ2nahE+DKrojaANc5Jo/7IVUgLv32TMXERbSBrkm60=; b=v4+eeJ9JgdFY1WupLLu6mXtO8iFNQZW5DGoihUZT45cpMhG/OlrwU+SFeTnENRTPPu sd1mgGTniEN1qCGbyp4zhNnNc0PxOYkuiyA3gsxNVpQWBCHKvSfMC/AeenxPmq3u05ka KHycllch0qiFOfq8HdLp0AfMtBRPt5q8TakwexWaYwiGvRWBXwqyoLH8RQzK277voVhK 60gyii02OALKcNXp8zIVbGGTQHgJtdhM6kUVjopgjeZpWi2zNKKyqHcXT9Qavb1E99qU iUXzH9JdzszfWHcqe+4ofFs3FfKKE8VvEueh+cJ5VAi+rx5GU++h8TP1SBnfBNeAQmYM urIg== MIME-Version: 1.0 X-Received: by 10.50.13.67 with SMTP id f3mr15304322igc.9.1400690453922; Wed, 21 May 2014 09:40:53 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 21 May 2014 09:40:53 -0700 (PDT) In-Reply-To: <20140521163742.GG9789@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163742.GG9789@pfrc> Date: Wed, 21 May 2014 18:40:53 +0200 X-Google-Sender-Auth: Az6fwyROQobktOggPT4wduOm24Q Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jH3W4okvGcJkYFrKguvMHcpl37I Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:40:56 -0000 It all depends how you implement your filters :) r. On Wed, May 21, 2014 at 6:37 PM, Jeffrey Haas wrote: > On Wed, May 21, 2014 at 06:33:24PM +0200, Robert Raszuk wrote: >> In the situations where protocol SAFI contains a mix (tagged and not >> tagged NLRIs with RTs) I would rather propose to amend the rfc to >> exchange default RT + specific RTs. That would potentially allow for >> reception of NLRIs with no RT attached + filtering of those against >> more specific RTs received which do carry RT ext community. > > Default RT-C effectively negates the usefulness of the feature. I wouldn't > recommend this. > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 21 09:46:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52961A0679 for ; Wed, 21 May 2014 09:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuhLpugao6bF for ; Wed, 21 May 2014 09:46:05 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69341A0183 for ; Wed, 21 May 2014 09:46:04 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id uy17so6439431igb.17 for ; Wed, 21 May 2014 09:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OUidLFsOHDpwfPlfBSr8At6lKnKFopYw1JeomjOdTXw=; b=v2O9L/osrm7xdckzFezI+WTqY8fWTrNlKr3gzBI0GK3Ux4VmriqeiGt0O7GouzTgwG OlHqJDijxYPOtlokn9guHVkEgEzWr10arLoEDyjo+LyMQ6ecLbsgJzn2iU/r/VteaEr7 F2Lw70tv/NtvZSLEqlU8RAEfmOCU2EV4BB4lQ3LKFTWOsFR+VfHNcWwtQDFM2aHrkpz9 9JlWKnK4Pv4U0DSdP4Tb+qFWiiXaXDZeA35I3LBU3n3HZ0DHv8kTqbEF34FFRiQtx2p5 697jWifzIzJiK0hV5CeysyJwlgIBQt/vFG/magswHVaz4Wnq48717XuS3z+9Dx6JFrn0 ZBaQ== MIME-Version: 1.0 X-Received: by 10.50.13.67 with SMTP id f3mr15344561igc.9.1400690763723; Wed, 21 May 2014 09:46:03 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 21 May 2014 09:46:03 -0700 (PDT) In-Reply-To: References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163621.GF9789@pfrc> Date: Wed, 21 May 2014 18:46:03 +0200 X-Google-Sender-Auth: lDbiimLWqr4pj_0BpgVAxLPATyM Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/eoiJTzpfC5miqX--eQ6vESpC3QI Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:46:05 -0000 Assume I do have a valid SR application to filter tiny subset of Internet table. For this I can mark such tiny subset of routes with RTs, enable RTC and activate RT filtering on IPv4 session. Sending full table there where I need only few routes would kill the optimization completely. Btw .. how do you handle the same problem with ORF ? r. On Wed, May 21, 2014 at 6:38 PM, Robert Raszuk wrote: >> While a complicating factor certainly, we'd still end up sending along those >> routes after either end-of-rib for RT-C or the timeout. (Presuming the >> implementation follows the SHOULD.) > > After timeout yes, but not after valid set of RTC RT NLRIs followed by > EOR. .. I would not expect to see those in the latter case. > > r. > >> So, while it causes potential delay to the subset of the routes carrying no >> RT, presumably they're in the same family because some of the routes will >> have an RT and want to benefit from the feature. >> >> -- Jeff From nobody Wed May 21 09:46:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605AE1A06B3 for ; Wed, 21 May 2014 09:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZjnIaKZbSnn for ; Wed, 21 May 2014 09:46:30 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BB12B1A06D3 for ; Wed, 21 May 2014 09:46:30 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E850BC277; Wed, 21 May 2014 12:46:29 -0400 (EDT) Date: Wed, 21 May 2014 12:46:29 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140521164629.GJ9789@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163621.GF9789@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/BceXXFgQbDddHdjhfnAA8vf3yqM Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:46:35 -0000 On Wed, May 21, 2014 at 06:38:49PM +0200, Robert Raszuk wrote: > > While a complicating factor certainly, we'd still end up sending along those > > routes after either end-of-rib for RT-C or the timeout. (Presuming the > > implementation follows the SHOULD.) > > After timeout yes, but not after valid set of RTC RT NLRIs followed by > EOR. .. I would not expect to see those in the latter case. I believe that's the point of contention. Should we be applying filters when there's nothing to match on? To echo a point Yakov raised in a side chat, what this would mean protocol-wise would be a NULL RT-C entry. This is distinct from a default which is a "match all". -- Jeff From nobody Wed May 21 09:48:53 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6767E1A070A for ; Wed, 21 May 2014 09:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOF--I6CWXdg for ; Wed, 21 May 2014 09:48:47 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C331A0834 for ; Wed, 21 May 2014 09:48:47 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id y20so2192555ier.6 for ; Wed, 21 May 2014 09:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tFDaV0iblFdibqq/APlAtW/VARMGB2ycwbLekXv49BE=; b=Y9UPlL25i0B58wR7J9C0trxoTsGxQc+a6Vc2rryMnZt1TWQIyomKNtbKhGi0Agzt0x HeDMFKrq0w3C+AistznYuW1WjA7oMCgi1MozSEDH708xOO4DbstPAXuKk6gZTOCvQno/ 89Y37BW1tj5wwCVV4/O/7R14fMVzc964rzizxE1m7y3P0YGjTlY/U4O+pgKTwBPV4cgX 3Mpz4agvyQhCKfFhtXcS7x4NAlmaogPIHhEQNrfXn8H24y0tniWZYLu04uVe5G1xB3MO pWnWrn6quNVEjxLjpHgLQOr2smBylHJnJ2zbVODzLjSlVD/dOQ1MGWhcQMfjmtl+Fjor wyCA== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr15176858igb.21.1400690926454; Wed, 21 May 2014 09:48:46 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 21 May 2014 09:48:46 -0700 (PDT) In-Reply-To: <20140521164629.GJ9789@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163621.GF9789@pfrc> <20140521164629.GJ9789@pfrc> Date: Wed, 21 May 2014 18:48:46 +0200 X-Google-Sender-Auth: XY1Ndp1xS5qhmRQfJyKXp6JtFRg Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jvl1JIrPnI4L9IdsyXAeP6FBXuA Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:48:48 -0000 Well I like Yakov's suggestion. Default was just an example - however his proposal behavior matches (at least mine) expectation :) So perhaps we should amend RFC4684 with NULL RT entry and encode it somehow different then DEFAULT RT entry. r. On Wed, May 21, 2014 at 6:46 PM, Jeffrey Haas wrote: > On Wed, May 21, 2014 at 06:38:49PM +0200, Robert Raszuk wrote: >> > While a complicating factor certainly, we'd still end up sending along those >> > routes after either end-of-rib for RT-C or the timeout. (Presuming the >> > implementation follows the SHOULD.) >> >> After timeout yes, but not after valid set of RTC RT NLRIs followed by >> EOR. .. I would not expect to see those in the latter case. > > I believe that's the point of contention. Should we be applying filters > when there's nothing to match on? > > To echo a point Yakov raised in a side chat, what this would mean > protocol-wise would be a NULL RT-C entry. This is distinct from a default > which is a "match all". > > -- Jeff From nobody Wed May 21 09:50:07 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CD81A0183 for ; Wed, 21 May 2014 09:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC9kbvIwhnUM for ; Wed, 21 May 2014 09:50:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E01761A0834 for ; Wed, 21 May 2014 09:50:01 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1B886C26A; Wed, 21 May 2014 12:50:01 -0400 (EDT) Date: Wed, 21 May 2014 12:50:01 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140521165001.GK9789@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163742.GG9789@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/rgD70qSZOGpU-S7ulhm6TglFKQY Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:50:06 -0000 On Wed, May 21, 2014 at 06:40:53PM +0200, Robert Raszuk wrote: > > Default RT-C effectively negates the usefulness of the feature. I wouldn't > > recommend this. > > It all depends how you implement your filters :) I'm not clear how this could be the case, even at a protocol abstraction level. Since RT-C entries are effectively longest match on RT (although I know there's a push to change that behavior as part of the IPv6 work), for any set of RT-Cs including default, any route containing an RT will match default. You're thus not constraining much at all. Modulo policy limiting the distribution of default in your network, of course. But I'm talking about on a single router. -- Jeff From nobody Wed May 21 09:55:35 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265441A085D for ; Wed, 21 May 2014 09:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojd0kG_Ye2uu for ; Wed, 21 May 2014 09:55:29 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48991A048D for ; Wed, 21 May 2014 09:55:17 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rl12so2288413iec.9 for ; Wed, 21 May 2014 09:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OuezuMxXZejBgKjumZ0uj+lggnR/X1LqDVABQ8iROjM=; b=F/xXUmi628WRg1xn1pEkI2Zud639fSugJ8jTorU8uwoNGtcFjOMep9h+TEKgKtsALO +vM7M3xnla7QfMxt4dJA+Zdx+1NIGL//+iGZWEGtcQLo+TzpZzmEXm0PSxFR++i87gdb 6LxmfXbp5khn73F6HZSWkYsBrpsb2kb1Hr0W7LzcESwY5Rn4jc3OYUNuaVxAIqQCs8M3 fPue0rSihjVHm+g3EBOEl66JZ+2HZvbanwCBRXLidIVPBIDTSz0MYyTb5BnqqamPleCn Nwo7BEOU1uiKgbWt0ClYRD35Tzr39TcMfYhRqtdZNiOpVFTPAv1XBU9CDkh15L7gcAU3 oZoQ== MIME-Version: 1.0 X-Received: by 10.42.52.199 with SMTP id k7mr49503516icg.4.1400691316430; Wed, 21 May 2014 09:55:16 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Wed, 21 May 2014 09:55:16 -0700 (PDT) In-Reply-To: <20140521165001.GK9789@pfrc> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521163742.GG9789@pfrc> <20140521165001.GK9789@pfrc> Date: Wed, 21 May 2014 18:55:16 +0200 X-Google-Sender-Auth: FtJNkZ71pjOtkvHZcRuEEJkh5iE Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/G2kQ72mwkEJdG_TnMiGQmyiuA9E Cc: idr wg , "erosen@cisco.com" Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 16:55:30 -0000 I meant that you do not execute the match of the default entry for routes which contain RT AND RTC send anything more specific then default RT. But NULL RT idea is much more elegant and does not require any of the above twicks. R. On Wed, May 21, 2014 at 6:50 PM, Jeffrey Haas wrote: > On Wed, May 21, 2014 at 06:40:53PM +0200, Robert Raszuk wrote: >> > Default RT-C effectively negates the usefulness of the feature. I wouldn't >> > recommend this. >> >> It all depends how you implement your filters :) > > I'm not clear how this could be the case, even at a protocol abstraction > level. Since RT-C entries are effectively longest match on RT (although I > know there's a push to change that behavior as part of the IPv6 work), for > any set of RT-Cs including default, any route containing an RT will match > default. You're thus not constraining much at all. > > Modulo policy limiting the distribution of default in your network, of > course. But I'm talking about on a single router. > > -- Jeff From nobody Thu May 22 03:57:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C381A0185; Thu, 22 May 2014 03:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-A8ddvanvU8; Thu, 22 May 2014 03:56:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F821A0140; Thu, 22 May 2014 03:56:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140522105658.26275.21121.idtracker@ietfa.amsl.com> Date: Thu, 22 May 2014 03:56:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/OhTmJh_FKRrmYiyPIViQGDa2wjs Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 10:56:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : North-Bound Distribution of Link-State and TE Information using BGP Authors : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Saikat Ray Filename : draft-ietf-idr-ls-distribution-05.txt Pages : 38 Date : 2014-05-22 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-ls-distribution-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 22 07:58:30 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F921A01E5 for ; Thu, 22 May 2014 07:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcJNHgNUWyGi for ; Thu, 22 May 2014 07:58:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5573D1A00C6 for ; Thu, 22 May 2014 07:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1405; q=dns/txt; s=iport; t=1400770706; x=1401980306; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LUjUUON5j+/klaeMHn822fDv9Y8VlQGG8i9Cu1WO1+I=; b=gKqNI2lyUWFXm5cj4trLJy4x4sw6uWj7FtT/XfX8gJfYdSIE+z2BvBGj qco4Bpsh4TlPDcoAr90YpGNt8BVpdHpeCbpax4c2ET/hwMkWjwu0cd57k i/r2bG/havwyZ1PcfTM0hi8f+HGynnQ4FUYlJ/kf1UkXOJLNxaOaBBh2Q k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYIAAoQflOtJA2I/2dsb2JhbABZgwdSWKlpBQGSf4c8AYENFnSCJwEEAQEBNzQLEgEIDigxBgslAgQBDQWILQMRDdAbDYYHEwSFVYZkgT1YB4RABJd8gXWNNIVygziBbkI X-IronPort-AV: E=Sophos;i="4.98,887,1392163200"; d="scan'208";a="327072331" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP; 22 May 2014 14:58:25 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4MEwOo4008869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 May 2014 14:58:24 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.72]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 22 May 2014 09:58:23 -0500 From: "Keyur Patel (keyupate)" To: Alia Atlas , "draft-ietf-idr-bgp-enhanced-route-refresh@tools.ietf.org" , "idr-chairs@tools.ietf.org" Thread-Topic: [Idr] AD review of draft-ietf-idr-bgp-enhanced-route-refresh-06 Thread-Index: AQHPdc5G8KucKVTVtU+EEBFMQTH66Q== Date: Thu, 22 May 2014 14:58:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.116.143] Content-Type: text/plain; charset="us-ascii" Content-ID: <2950C6CDC1077E47BDD8217784E00367@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/f2NcvfJZoBskwo0A_m0OX7uHn0I Cc: "idr@ietf. org" , "idr-ads@tools.ietf.org" Subject: Re: [Idr] AD review of draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:58:29 -0000 Hi Alia, Thanks for the feedback. Comments are inlined. #Keyur On 5/20/14 3:37 PM, "Alia Atlas" wrote: >As part of my routine evaluation of drafts before progressing them to >IETF Last Call, >I do a review. This draft is very clearly written and I have only a >couple comments. > >Please do respond and update the draft - but I am also starting the >IETF Last Call in >parallel with the discussion. An updated version should be made >available before June 5 or I will have to remove it from the IESG >telechat scheduled for May 12. > >Comments: > >a) The draft should update RFC2918, given that it is redefining the >"Reserved" field of the ROUTE-REFRESH message. #Keyur: ack. > >b) I see that all 8 bits of the RESERVED field are being used for this >purpose. Is there a reason to do so, given that only 3 values have a >planned use? I know that there are existing implementations and I >don't have another plan for those values - just general conservation. >(Imagine wanting to do the same procedure but for a more limited scope >of routes.) #Keyur: We have redefined the "Reserved" field to Message sub-type. 3 bits are used. Remaining are reserved for future use. Regards, Keyur > >Thanks, >Alia > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 22 13:43:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7061A1A0283 for ; Thu, 22 May 2014 13:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.053 X-Spam-Level: * X-Spam-Status: No, score=1.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqpsqWNS_7dE for ; Thu, 22 May 2014 13:43:05 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9291A0305 for ; Thu, 22 May 2014 13:42:51 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: Chris Hall , "'idr@ietf. org'" Thread-Topic: [Idr] draft-ietf-idr-error-handling-08 Thread-Index: AQHPbwtk1xERpD0lLEmW7ezhqdBFfJs/rNcAgAAvwgCADOrwUA== Date: Thu, 22 May 2014 20:42:47 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> In-Reply-To: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.44.10] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/92udzqE1nlxPWndSMJ8lzjWdGh4 Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:43:07 -0000 I agree with Chris on this one, It essentially boils down to whether lost-NRLI (as defined by Chris) is wor= se than session reset. My opinion is that session reset is worse. =20 adam > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Chris Hall > Sent: Wednesday, May 14, 2014 2:15 PM > To: 'idr@ietf. org' > Subject: Re: [Idr] draft-ietf-idr-error-handling-08 >=20 > Thomas Mangin wrote (on Wed 14-May-2014 at 10:24 +0100): > .... > > >> There are any number of heuristics that may be applied to this > > >> problem. It would be helpful if, in practice, the vast majority of > > >> implementations only ever send one set of NLRI per message. It > > >> helps a bit if, in practice, MP_xx_REACH attributes only appear in > > >> messages where both the Withdraw Routes and NLRI parts are empty. > > >> Does anybody know if either of these is the case ? >=20 > > > I (strongly) believe these to be common practice. I'm confident of > > > it for the code base I've currently got access to, but can't speak > > > authoritatively for others of course. > > > Maybe other folks will chime in. >=20 > > I know I never give this a thought. Chris, could you please elaborate > > on why you seen this behaviour as advisable ? >=20 > OK... you asked, so here goes... >=20 > ...in the following: "MP_xx_NLRI" means one or both of MP_REACH_NLRI > and MP_UNREACH_NLRI attributes; Body-NLRI refers to one or both of the > Withdrawn Routes and NLRI sections of the UPDATE message -- the NLRI > outside the attributes; a "set of NLRI" refers to any one of the MP_xx_NL= RI > and Body-NLRI; and "NLRI" refers to any or all sets of NLRI in an UPDATE > message. >=20 > ...and this is my understanding of the problem... >=20 > ...(1) for treat-as-withdraw to be "safe" (or as safe as possible) it is = essential > that *all* NLRI in a broken update can be recovered. For if not, then tr= eat- > as-withdraw is "incomplete", and leaves the receiver with out-of-date rou= tes > in its hands, whose value is (to say the least) indeterminate. >=20 > ...(2) the standard(s) allow for an UPDATE to contain between 1 and 4 set= s of > NLRI. >=20 > ...(3) depending on how broken the message is, there may be 0, 1 or 2 > MP_xx_NLRI attributes buried somewhere in the rubble, and the receiver > cannot tell how much has been lost -- the lost-NLRI. If there are no Bod= y- > NLRI, then the receiver may assume that there are 1 or 2 lost-NLRI. >=20 > ...(4) if the sender follows the MP_xx_NLRI first rule, they sit on top o= f the > rubble and can be recovered. This is a change in the standard which one > hopes will be implemented and deployed in some time. But in any case, th= e > receiver has no way of telling whether the sender intends to follow the r= ule > (or has succeeded !). So, if the receiver does not find MP_xx_NLRI, it m= ay > have to assume the worst. >=20 > ...(5) if lost-NLRI are a problem, or a problem worse than session-reset,= then > the receiver appears to be in the unenviable position of having to balanc= e > the risk/cost of an "incomplete" > treat-as-withdraw against the benefit of avoiding (the dreaded) session- > reset. >=20 > ...(6) if some/many/most/all lost-NLRI are worse than session-reset, then > when can treat-as-withdraw be used ? >=20 > At this point I go and hide under my desk. >=20 > But, if in practice an UPDATE only ever contains 1 set of NLRI, then my > descent into a paranoid, quivering wreck stops at step 2. Hurrah ! >=20 > This is slightly stricter than it needs to be: there is no problem with b= oth sets > of body-NLRI appearing together. >=20 > Now, you can argue that the only thing a receiver *can* do is to treat-as= - > withdraw on the basis of the NLRI it can see, and not worry about things = it > cannot see -- so that's what it *ought* to do. As a practical matter, er= rors are > rare... errors which result in lost-NLRI are rarer still... the result is= probably > not as bad as session-reset... and the operator should be got out of bed = to > deal with the root-cause pretty sharpish, so any bad effects will be > temporary... and in any case treat-as-withdraw is not a perfect work-arou= nd, > just the best we have. Trying to decide when it is more or less likely t= hat > there are lost-NLRI -- searching through the rubble for possible survivor= s -- > looks like a tricky problem, and best avoided. >=20 > If, de facto, the receiver can assume that messages contain either body-N= LRI > or just one MP_xx_NLRI attribute, then what the receiver > *can* do doesn't change, but what it *ought* to do is less problematic, a= nd > the rationale requires much, much less hand waving. >=20 > It's not necessary for absolutely every sender to be absolutely guarantee= d to > follow this (post hoc) rule. For the minority that don't work this way, = the > hand waving argument may be deployed. But the smaller that minority is, > the less vigorous the hand waving has to be to make the point. >=20 > For completeness, note that the MP_xx_NLRI at the front rule is orthogona= l > to this. Senders which follow the rule are less likely to generate a bro= ken > UPDATE from which the NLRI cannot be recovered. The rule is not relevant > to what the receiver does with the UPDATE. >=20 > Chris >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 22 15:54:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4301A0226 for ; Thu, 22 May 2014 15:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iBewg3UIkA5 for ; Thu, 22 May 2014 15:54:42 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386891A017D for ; Thu, 22 May 2014 15:54:42 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id wp4so4383293obc.8 for ; Thu, 22 May 2014 15:54:40 -0700 (PDT) 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=R3k0vtuCjZXoJjCnvIG+Jfvm24wJW9ClF6o4Pku61zg=; b=gdmsQNcIRyEIq1MBfgg3lpQCu7BCj5fI4FATdqSL8kr8dh36VUDFzlnHylp9T72/gx NqjMDSxbiKwUYXovZF3YZLAmj615Pxl0v1EXcziyFEDcqbacK/6EFE7taWZo0PVsSLRF 3XiHNsFURIbSO8+KLkUCtMRN9YetonvS6pqk++kU1pgn9IOCZq1jcjfoZGtCFSryuXf9 981R5iSFIaqgq7QNFT4WEZHLfYeiom787Tl9G/7rq4Yghxnx7MRBK9kz2lGNSYpSiBOl 9IrlM1PvzHtZHghZQVwemtuIEW/1bgw2sLlCGGUo9I1R1nMnSwND+7x+JQVzeaLlJh9e wy5Q== MIME-Version: 1.0 X-Received: by 10.60.63.142 with SMTP id g14mr822007oes.72.1400799280509; Thu, 22 May 2014 15:54:40 -0700 (PDT) Received: by 10.76.71.162 with HTTP; Thu, 22 May 2014 15:54:40 -0700 (PDT) In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> Date: Thu, 22 May 2014 15:54:40 -0700 Message-ID: From: Shyam Sethuram To: =?UTF-8?Q?Vitkovsk=C3=BD_Adam?= Content-Type: multipart/alternative; boundary=001a11c1d9c08439b504fa04ff02 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/mhCDSCBke4IEO00QU2U_0fhQzGo Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 22:54:44 -0000 --001a11c1d9c08439b504fa04ff02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd say 'lost-NLRI' is worse than session reset. You end up with stale routes (forwarding to invalid nexthop, importing to the wrong VRF, etc). IMO if you can't successfully parse a full set of NLRIs, then session reset would be the better. shyam On Thu, May 22, 2014 at 1:42 PM, Vitkovsk=C3=BD Adam wrote: > I agree with Chris on this one, > It essentially boils down to whether lost-NRLI (as defined by Chris) is > worse than session reset. > My opinion is that session reset is worse. > > > adam > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Chris Hall > > Sent: Wednesday, May 14, 2014 2:15 PM > > To: 'idr@ietf. org' > > Subject: Re: [Idr] draft-ietf-idr-error-handling-08 > > > > Thomas Mangin wrote (on Wed 14-May-2014 at 10:24 +0100): > > .... > > > >> There are any number of heuristics that may be applied to this > > > >> problem. It would be helpful if, in practice, the vast majority o= f > > > >> implementations only ever send one set of NLRI per message. It > > > >> helps a bit if, in practice, MP_xx_REACH attributes only appear in > > > >> messages where both the Withdraw Routes and NLRI parts are empty. > > > >> Does anybody know if either of these is the case ? > > > > > > I (strongly) believe these to be common practice. I'm confident of > > > > it for the code base I've currently got access to, but can't speak > > > > authoritatively for others of course. > > > > Maybe other folks will chime in. > > > > > I know I never give this a thought. Chris, could you please elaborate > > > on why you seen this behaviour as advisable ? > > > > OK... you asked, so here goes... > > > > ...in the following: "MP_xx_NLRI" means one or both of MP_REACH_NLRI > > and MP_UNREACH_NLRI attributes; Body-NLRI refers to one or both of the > > Withdrawn Routes and NLRI sections of the UPDATE message -- the NLRI > > outside the attributes; a "set of NLRI" refers to any one of the > MP_xx_NLRI > > and Body-NLRI; and "NLRI" refers to any or all sets of NLRI in an UPDAT= E > > message. > > > > ...and this is my understanding of the problem... > > > > ...(1) for treat-as-withdraw to be "safe" (or as safe as possible) it i= s > essential > > that *all* NLRI in a broken update can be recovered. For if not, then > treat- > > as-withdraw is "incomplete", and leaves the receiver with out-of-date > routes > > in its hands, whose value is (to say the least) indeterminate. > > > > ...(2) the standard(s) allow for an UPDATE to contain between 1 and 4 > sets of > > NLRI. > > > > ...(3) depending on how broken the message is, there may be 0, 1 or 2 > > MP_xx_NLRI attributes buried somewhere in the rubble, and the receiver > > cannot tell how much has been lost -- the lost-NLRI. If there are no > Body- > > NLRI, then the receiver may assume that there are 1 or 2 lost-NLRI. > > > > ...(4) if the sender follows the MP_xx_NLRI first rule, they sit on top > of the > > rubble and can be recovered. This is a change in the standard which on= e > > hopes will be implemented and deployed in some time. But in any case, > the > > receiver has no way of telling whether the sender intends to follow the > rule > > (or has succeeded !). So, if the receiver does not find MP_xx_NLRI, it > may > > have to assume the worst. > > > > ...(5) if lost-NLRI are a problem, or a problem worse than > session-reset, then > > the receiver appears to be in the unenviable position of having to > balance > > the risk/cost of an "incomplete" > > treat-as-withdraw against the benefit of avoiding (the dreaded) session= - > > reset. > > > > ...(6) if some/many/most/all lost-NLRI are worse than session-reset, th= en > > when can treat-as-withdraw be used ? > > > > At this point I go and hide under my desk. > > > > But, if in practice an UPDATE only ever contains 1 set of NLRI, then my > > descent into a paranoid, quivering wreck stops at step 2. Hurrah ! > > > > This is slightly stricter than it needs to be: there is no problem with > both sets > > of body-NLRI appearing together. > > > > Now, you can argue that the only thing a receiver *can* do is to > treat-as- > > withdraw on the basis of the NLRI it can see, and not worry about thing= s > it > > cannot see -- so that's what it *ought* to do. As a practical matter, > errors are > > rare... errors which result in lost-NLRI are rarer still... the result > is probably > > not as bad as session-reset... and the operator should be got out of be= d > to > > deal with the root-cause pretty sharpish, so any bad effects will be > > temporary... and in any case treat-as-withdraw is not a perfect > work-around, > > just the best we have. Trying to decide when it is more or less likely > that > > there are lost-NLRI -- searching through the rubble for possible > survivors -- > > looks like a tricky problem, and best avoided. > > > > If, de facto, the receiver can assume that messages contain either > body-NLRI > > or just one MP_xx_NLRI attribute, then what the receiver > > *can* do doesn't change, but what it *ought* to do is less problematic, > and > > the rationale requires much, much less hand waving. > > > > It's not necessary for absolutely every sender to be absolutely > guaranteed to > > follow this (post hoc) rule. For the minority that don't work this way= , > the > > hand waving argument may be deployed. But the smaller that minority is= , > > the less vigorous the hand waving has to be to make the point. > > > > For completeness, note that the MP_xx_NLRI at the front rule is > orthogonal > > to this. Senders which follow the rule are less likely to generate a > broken > > UPDATE from which the NLRI cannot be recovered. The rule is not releva= nt > > to what the receiver does with the UPDATE. > > > > Chris > > > > > > > > _______________________________________________ > > 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 > --001a11c1d9c08439b504fa04ff02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd say 'lost-NLRI' is worse than session rese= t. You end up
with stale routes (forwarding to invalid nexthop, importi= ng to the wrong VRF, etc).
IMO if you can't successfully pars= e a full set of NLRIs, then session reset
would be the better.

shyam


On Thu, May 22, 2014= at 1:42 PM, Vitkovsk=C3=BD Adam <adam.vitkovsky@swan.sk> wrote:
I agree with Chris on this one,
It essentially boils down to whether lost-NRLI (as defined by Chris) is wor= se than session reset.
My opinion is that session reset is worse.


adam
> -----Original Message-----
> From: Idr [mailto:idr-bounces@= ietf.org] On Behalf Of Chris Hall
> Sent: Wednesday, May 14, 2014 2:15 PM
> To: 'idr@ietf. org'
> Subject: Re: [Idr] draft-ietf-idr-error-handling-08
>
> Thomas Mangin wrote (on Wed 14-May-2014 at 10:24 +0100):
> ....
> > >> There are any number of heuristics that may be applied t= o this
> > >> problem. =C2=A0It would be helpful if, in practice, the = vast majority of
> > >> implementations only ever send one set of NLRI per messa= ge. =C2=A0It
> > >> helps a bit if, in practice, MP_xx_REACH attributes only= appear in
> > >> messages where both the Withdraw Routes and NLRI parts a= re empty.
> > >> Does anybody know if either of these is the case ?
>
> > > I (strongly) believe these to be common practice. I'm co= nfident of
> > > it for the code base I've currently got access to, but c= an't speak
> > > authoritatively for others of course.
> > > Maybe other folks will chime in.
>
> > I know I never give this a thought. Chris, could you please elabo= rate
> > on why you seen this behaviour as advisable ?
>
> OK... you asked, so here goes...
>
> ...in the following: "MP_xx_NLRI" means one or both of MP_RE= ACH_NLRI
> and MP_UNREACH_NLRI attributes; Body-NLRI refers to one or both of the=
> Withdrawn Routes and NLRI sections of the UPDATE message -- the NLRI > outside the attributes; a "set of NLRI" refers to any one of= the MP_xx_NLRI
> and Body-NLRI; and "NLRI" refers to any or all sets of NLRI = in an UPDATE
> message.
>
> ...and this is my understanding of the problem...
>
> ...(1) for treat-as-withdraw to be "safe" (or as safe as pos= sible) it is essential
> that *all* NLRI in a broken update can be recovered. =C2=A0For if not,= then treat-
> as-withdraw is "incomplete", and leaves the receiver with ou= t-of-date routes
> in its hands, whose value is (to say the least) indeterminate.
>
> ...(2) the standard(s) allow for an UPDATE to contain between 1 and 4 = sets of
> NLRI.
>
> ...(3) depending on how broken the message is, there may be 0, 1 or 2<= br> > MP_xx_NLRI attributes buried somewhere in the rubble, and the receiver=
> cannot tell how much has been lost -- the lost-NLRI. =C2=A0If there ar= e no Body-
> NLRI, then the receiver may assume that there are 1 or 2 lost-NLRI. >
> ...(4) if the sender follows the MP_xx_NLRI first rule, they sit on to= p of the
> rubble and can be recovered. =C2=A0This is a change in the standard wh= ich one
> hopes will be implemented and deployed in some time. =C2=A0But in any = case, the
> receiver has no way of telling whether the sender intends to follow th= e rule
> (or has succeeded !). =C2=A0So, if the receiver does not find MP_xx_NL= RI, it may
> have to assume the worst.
>
> ...(5) if lost-NLRI are a problem, or a problem worse than session-res= et, then
> the receiver appears to be in the unenviable position of having to bal= ance
> the risk/cost of an "incomplete"
> treat-as-withdraw against the benefit of avoiding (the dreaded) sessio= n-
> reset.
>
> ...(6) if some/many/most/all lost-NLRI are worse than session-reset, t= hen
> when can treat-as-withdraw be used ?
>
> At this point I go and hide under my desk.
>
> But, if in practice an UPDATE only ever contains 1 set of NLRI, then m= y
> descent into a paranoid, quivering wreck stops at step 2. =C2=A0Hurrah= !
>
> This is slightly stricter than it needs to be: there is no problem wit= h both sets
> of body-NLRI appearing together.
>
> Now, you can argue that the only thing a receiver *can* do is to treat= -as-
> withdraw on the basis of the NLRI it can see, and not worry about thin= gs it
> cannot see -- so that's what it *ought* to do. =C2=A0As a practica= l matter, errors are
> rare... errors which result in lost-NLRI are rarer still... the result= is probably
> not as bad as session-reset... and the operator should be got out of b= ed to
> deal with the root-cause pretty sharpish, so any bad effects will be > temporary... and in any case treat-as-withdraw is not a perfect work-a= round,
> just the best we have. =C2=A0Trying to decide when it is more or less = likely that
> there are lost-NLRI -- searching through the rubble for possible survi= vors --
> looks like a tricky problem, and best avoided.
>
> If, de facto, the receiver can assume that messages contain either bod= y-NLRI
> or just one MP_xx_NLRI attribute, then what the receiver
> *can* do doesn't change, but what it *ought* to do is less problem= atic, and
> the rationale requires much, much less hand waving.
>
> It's not necessary for absolutely every sender to be absolutely gu= aranteed to
> follow this (post hoc) rule. =C2=A0For the minority that don't wor= k this way, the
> hand waving argument may be deployed. =C2=A0But the smaller that minor= ity is,
> the less vigorous the hand waving has to be to make the point.
>
> For completeness, note that the MP_xx_NLRI at the front rule is orthog= onal
> to this. =C2=A0Senders which follow the rule are less likely to genera= te a broken
> UPDATE from which the NLRI cannot be recovered. =C2=A0The rule is not = relevant
> to what the receiver does with the UPDATE.
>
> Chris
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

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

--001a11c1d9c08439b504fa04ff02-- From nobody Thu May 22 16:36:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB7A1A024B for ; Thu, 22 May 2014 16:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVfByWQzBQFd for ; Thu, 22 May 2014 16:36:03 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6481A0248 for ; Thu, 22 May 2014 16:36:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id EA2B9C2D8; Thu, 22 May 2014 19:36:01 -0400 (EDT) Date: Thu, 22 May 2014 19:36:01 -0400 From: Jeffrey Haas To: Shyam Sethuram Message-ID: <20140522233601.GB561@pfrc> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Nko45y_XT-l8lJiBsilKpd4iunw Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 23:36:04 -0000 On Thu, May 22, 2014 at 03:54:40PM -0700, Shyam Sethuram wrote: > I'd say 'lost-NLRI' is worse than session reset. You end up > with stale routes (forwarding to invalid nexthop, importing to the wrong > VRF, etc). > IMO if you can't successfully parse a full set of NLRIs, then session reset > would be the better. Speaking as from a vendor who has this particular sin to live down, this somewhat argues a vendor-wide need of the ability to delete via CLI (and not policy and reconfig) a received BGP route. (Whack, as Steve Kent is known to say.) -- Jeff From nobody Thu May 22 17:27:19 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620B11A028E for ; Thu, 22 May 2014 17:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSFxwK0Yqxt3 for ; Thu, 22 May 2014 17:27:15 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462FE1A0274 for ; Thu, 22 May 2014 17:27:15 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hl10so59325igb.9 for ; Thu, 22 May 2014 17:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=amGpD5QxldPfE2HnlXuk6VOx3ntxEFtLjfXOchDMVM8=; b=i77y+I2UmNUfSApxjTlkYuAP7LmbOxIVbOgZSCEyivBDtIlJh1THv1q6WI1LzFlbjX OOf8JMAyUZKAglG11cUMUKn4TJUbC+tcX4s5Bf04qkWxwo0M9xbJILT3qJ1bfUTbpqVR IwN8tGYEBTGnegVPNmztiDJDTKbn8FnTeZAoNpZOvH4Uz05s4PyIhvcNPNHT+BGs6Rg2 wwSxTnVlmk07qP290rxs10T+rsOdnWIFEaPZ4HmhknFDf99u0FxHPdRdKIxj2mhkiewr lG/rKKTfT124Meb1qo6XHwR+B9j3pjSlxa3pZSE57+DjkTZZEbA/Dg+zNEjciQZGzgRb 6wEQ== MIME-Version: 1.0 X-Received: by 10.50.62.51 with SMTP id v19mr101401igr.21.1400804832589; Thu, 22 May 2014 17:27:12 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Thu, 22 May 2014 17:27:12 -0700 (PDT) Received: by 10.64.242.198 with HTTP; Thu, 22 May 2014 17:27:12 -0700 (PDT) In-Reply-To: <20140522233601.GB561@pfrc> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <20140522233601.GB561@pfrc> Date: Fri, 23 May 2014 02:27:12 +0200 X-Google-Sender-Auth: VrliDpW2oPhLEHPlXFYmP-KPYIg Message-ID: From: Robert Raszuk To: PFRC - jhaas Content-Type: multipart/alternative; boundary=047d7bdc18e6723cad04fa064a04 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vFCC4LY6nyd1lhabxKkU0POmQK8 Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 00:27:16 -0000 --047d7bdc18e6723cad04fa064a04 Content-Type: text/plain; charset=UTF-8 Jeff, But when you delete route via cli you hopefully withdraw it if it was advertised right ? However of you can not parse nlri you do not have such option. R. On May 22, 2014 4:36 PM, "Jeffrey Haas" wrote: > On Thu, May 22, 2014 at 03:54:40PM -0700, Shyam Sethuram wrote: > > I'd say 'lost-NLRI' is worse than session reset. You end up > > with stale routes (forwarding to invalid nexthop, importing to the wrong > > VRF, etc). > > IMO if you can't successfully parse a full set of NLRIs, then session > reset > > would be the better. > > Speaking as from a vendor who has this particular sin to live down, this > somewhat argues a vendor-wide need of the ability to delete via CLI (and > not > policy and reconfig) a received BGP route. (Whack, as Steve Kent is known > to say.) > > -- Jeff > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7bdc18e6723cad04fa064a04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Jeff,

But when you delete route via cli you hopefully withdraw it = if it was advertised right ?

However of you can not parse nlri you do not have such optio= n.

R.

On May 22, 2014 4:36 PM, "Jeffrey Haas"= ; <jhaas@pfrc.org> wrote:
On Thu, May 22, 2014 at 03:54:40PM -0700, Shyam Sethuram wrote:
> I'd say 'lost-NLRI' is worse than session reset. You end u= p
> with stale routes (forwarding to invalid nexthop, importing to the wro= ng
> VRF, etc).
> IMO if you can't successfully parse a full set of NLRIs, then sess= ion reset
> would be the better.

Speaking as from a vendor who has this particular sin to live down, this somewhat argues a vendor-wide need of the ability to delete via CLI (and no= t
policy and reconfig) a received BGP route. =C2=A0(Whack, as Steve Kent is k= nown
to say.)

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
--047d7bdc18e6723cad04fa064a04-- From nobody Fri May 23 06:50:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D611A04A4 for ; Fri, 23 May 2014 06:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKRZSM3qxeRq for ; Fri, 23 May 2014 06:49:59 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4935E1A04E7 for ; Fri, 23 May 2014 06:49:59 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9E836C26A; Fri, 23 May 2014 09:49:57 -0400 (EDT) Date: Fri, 23 May 2014 09:49:57 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140523134957.GC561@pfrc> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <20140522233601.GB561@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/18_fIS8otemJc6Z6XonFfeNOOyU Cc: idr wg Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 13:50:06 -0000 On Fri, May 23, 2014 at 02:27:12AM +0200, Robert Raszuk wrote: > But when you delete route via cli you hopefully withdraw it if it was > advertised right ? If we want to wrapper my statements in all the nice formalisms of BGP, consider it "manually removing a route from the Adj-Rib-In". One would expect the rest of the BGP machinery to Do The Right Thing. -- Jeff From nobody Fri May 23 07:21:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF86A1A01AF for ; Fri, 23 May 2014 07:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKN7lmKMG20Q for ; Fri, 23 May 2014 07:21:01 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CDB1A01B3 for ; Fri, 23 May 2014 07:21:00 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: Jeffrey Haas , Shyam Sethuram Thread-Topic: [Idr] draft-ietf-idr-error-handling-08 Thread-Index: AQHPbwtk1xERpD0lLEmW7ezhqdBFfJs/rNcAgAAvwgCADOrwUIAAWnkAgAALjYCAARLuYA== Date: Fri, 23 May 2014 14:20:53 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011EE426@EX01.swan.local> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <20140522233601.GB561@pfrc> In-Reply-To: <20140522233601.GB561@pfrc> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.40.93] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vR_p7k9PH2V-6o8ulwRJ2IasBDs Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 14:21:03 -0000 Ok so the reasoning behind this, if I understand it correctly, is that if t= he NLRI can't be parsed than BGP doesn't know for which NLRI to send a with= draw for so it rather sends a withdraw for all the routes from the neighbor= (by means of resetting the session with the neighbor).=20 But the neighbor might be perfectly fine with the routes we have sent to hi= m so why to reset the session and sending withdraws on both TX and RX path = from the incident. Can't the withdraw be sent just on the RX path and on the TX side the BGP c= ould just request a retransmit of all the routes from the neighbor. Well and only after it receives the similar garbage again than it can assum= e there's something seriously wrong with the neighbor and that maybe a sess= ion reset can solve things or draw operator's attention. adam > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Friday, May 23, 2014 1:36 AM > To: Shyam Sethuram > Cc: Vitkovsk=FD Adam; idr@ietf. org > Subject: Re: [Idr] draft-ietf-idr-error-handling-08 >=20 > On Thu, May 22, 2014 at 03:54:40PM -0700, Shyam Sethuram wrote: > > I'd say 'lost-NLRI' is worse than session reset. You end up with stale > > routes (forwarding to invalid nexthop, importing to the wrong VRF, > > etc). > > IMO if you can't successfully parse a full set of NLRIs, then session > > reset would be the better. >=20 > Speaking as from a vendor who has this particular sin to live down, this > somewhat argues a vendor-wide need of the ability to delete via CLI (and = not > policy and reconfig) a received BGP route. (Whack, as Steve Kent is know= n to > say.) >=20 > -- Jeff From nobody Fri May 23 10:09:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F211A076B for ; Fri, 23 May 2014 10:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jANEfbtHHSiv for ; Fri, 23 May 2014 10:09:11 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3091A06E6 for ; Fri, 23 May 2014 10:08:48 -0700 (PDT) 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 s4NH8i25028335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2014 12:08:44 -0500 (CDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 54C8B1E0075; Fri, 23 May 2014 12:08:39 -0500 (CDT) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 3804D1E0074; Fri, 23 May 2014 12:08:39 -0500 (CDT) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s4NH8c3R007342; Fri, 23 May 2014 12:08:38 -0500 (CDT) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id s4NH8bLr007314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 May 2014 12:08:38 -0500 (CDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0158.001; Fri, 23 May 2014 11:08:39 -0600 From: "Smith, Donald" To: Shyam Sethuram , =?iso-8859-1?Q?Vitkovsk=FD_Adam?= Thread-Topic: [Idr] draft-ietf-idr-error-handling-08 Thread-Index: AQHPbwtijIW44tHLwk+T170Dz/t/4JtAMvMAgAAvwgCADSCQgIAAJNkAgADLIIY= Date: Fri, 23 May 2014 17:08:37 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/kVElcmZnwdylWgpMBnNmPKlemgE Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 17:09:12 -0000 I would totally disagree. Despite it's dynamic nature peering routes don't = change (completely) nearly as often as people seem to think. Thus the whole= concept of GR. Add to that the fact that ipv4 is "exhausted" churn isn't a= s constant as people seem to believe. We need bgp to "heal" the network wh= en one link goes down but if it does NOT the worse that happens is it doesn= 't self heal for the portion that is broken. A reset kills ALL the routes b= etween bgp speakers not just the broken link. You can't amputate the leg to save the foot. You can amputate the foot to = save the leg. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: Idr [idr-bounces@ietf.org] on behalf of Shyam Sethuram [shyam.ioml@gm= ail.com] Sent: Thursday, May 22, 2014 4:54 PM To: Vitkovsk=FD Adam Cc: idr@ietf. org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 I'd say 'lost-NLRI' is worse than session reset. You end up=20 with stale routes (forwarding to invalid nexthop, importing to the wrong VR= F, etc). IMO if you can't successfully parse a full set of NLRIs, then session reset would be the better. shyam On Thu, May 22, 2014 at 1:42 PM, Vitkovsk=FD Adam = wrote: I agree with Chris on this one, It essentially boils down to whether lost-NRLI (as defined by Chris) is wor= se than session reset. My opinion is that session reset is worse. adam > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Chris Hall > Sent: Wednesday, May 14, 2014 2:15 PM > To: 'idr@ietf. org' > Subject: Re: [Idr] draft-ietf-idr-error-handling-08 > > Thomas Mangin wrote (on Wed 14-May-2014 at 10:24 +0100): > .... > > >> There are any number of heuristics that may be applied to this > > >> problem. It would be helpful if, in practice, the vast majority of > > >> implementations only ever send one set of NLRI per message. It > > >> helps a bit if, in practice, MP_xx_REACH attributes only appear in > > >> messages where both the Withdraw Routes and NLRI parts are empty. > > >> Does anybody know if either of these is the case ? > > > > I (strongly) believe these to be common practice. I'm confident of > > > it for the code base I've currently got access to, but can't speak > > > authoritatively for others of course. > > > Maybe other folks will chime in. > > > I know I never give this a thought. Chris, could you please elaborate > > on why you seen this behaviour as advisable ? > > OK... you asked, so here goes... > > ...in the following: "MP_xx_NLRI" means one or both of MP_REACH_NLRI > and MP_UNREACH_NLRI attributes; Body-NLRI refers to one or both of the > Withdrawn Routes and NLRI sections of the UPDATE message -- the NLRI > outside the attributes; a "set of NLRI" refers to any one of the MP_xx_NL= RI > and Body-NLRI; and "NLRI" refers to any or all sets of NLRI in an UPDATE > message. > > ...and this is my understanding of the problem... > > ...(1) for treat-as-withdraw to be "safe" (or as safe as possible) it is = essential > that *all* NLRI in a broken update can be recovered. For if not, then tr= eat- > as-withdraw is "incomplete", and leaves the receiver with out-of-date rou= tes > in its hands, whose value is (to say the least) indeterminate. > > ...(2) the standard(s) allow for an UPDATE to contain between 1 and 4 set= s of > NLRI. > > ...(3) depending on how broken the message is, there may be 0, 1 or 2 > MP_xx_NLRI attributes buried somewhere in the rubble, and the receiver > cannot tell how much has been lost -- the lost-NLRI. If there are no Bod= y- > NLRI, then the receiver may assume that there are 1 or 2 lost-NLRI. > > ...(4) if the sender follows the MP_xx_NLRI first rule, they sit on top o= f the > rubble and can be recovered. This is a change in the standard which one > hopes will be implemented and deployed in some time. But in any case, th= e > receiver has no way of telling whether the sender intends to follow the r= ule > (or has succeeded !). So, if the receiver does not find MP_xx_NLRI, it m= ay > have to assume the worst. > > ...(5) if lost-NLRI are a problem, or a problem worse than session-reset,= then > the receiver appears to be in the unenviable position of having to balanc= e > the risk/cost of an "incomplete" > treat-as-withdraw against the benefit of avoiding (the dreaded) session- > reset. > > ...(6) if some/many/most/all lost-NLRI are worse than session-reset, then > when can treat-as-withdraw be used ? > > At this point I go and hide under my desk. > > But, if in practice an UPDATE only ever contains 1 set of NLRI, then my > descent into a paranoid, quivering wreck stops at step 2. Hurrah ! > > This is slightly stricter than it needs to be: there is no problem with b= oth sets > of body-NLRI appearing together. > > Now, you can argue that the only thing a receiver *can* do is to treat-as= - > withdraw on the basis of the NLRI it can see, and not worry about things = it > cannot see -- so that's what it *ought* to do. As a practical matter, er= rors are > rare... errors which result in lost-NLRI are rarer still... the result is= probably > not as bad as session-reset... and the operator should be got out of bed = to > deal with the root-cause pretty sharpish, so any bad effects will be > temporary... and in any case treat-as-withdraw is not a perfect work-arou= nd, > just the best we have. Trying to decide when it is more or less likely t= hat > there are lost-NLRI -- searching through the rubble for possible survivor= s -- > looks like a tricky problem, and best avoided. > > If, de facto, the receiver can assume that messages contain either body-N= LRI > or just one MP_xx_NLRI attribute, then what the receiver > *can* do doesn't change, but what it *ought* to do is less problematic, a= nd > the rationale requires much, much less hand waving. > > It's not necessary for absolutely every sender to be absolutely guarantee= d to > follow this (post hoc) rule. For the minority that don't work this way, = the > hand waving argument may be deployed. But the smaller that minority is, > the less vigorous the hand waving has to be to make the point. > > For completeness, note that the MP_xx_NLRI at the front rule is orthogona= l > to this. Senders which follow the rule are less likely to generate a bro= ken > UPDATE from which the NLRI cannot be recovered. The rule is not relevant > to what the receiver does with the UPDATE. > > Chris > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr= From nobody Fri May 23 14:27:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6951D1A008C for ; Fri, 23 May 2014 14:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBOvqQKnrItr for ; Fri, 23 May 2014 14:27:12 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DE81A006D for ; Fri, 23 May 2014 14:27:11 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: "Smith, Donald" , Shyam Sethuram Thread-Topic: [Idr] draft-ietf-idr-error-handling-08 Thread-Index: AQHPbwtk1xERpD0lLEmW7ezhqdBFfJs/rNcAgAAvwgCADOrwUIAAWnkAgAExpYCAAGdwgA== Date: Fri, 23 May 2014 21:27:02 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local>, <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.44.10] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vM7kf5gXTpTk8k6czcq9H-Njr0A Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 21:27:14 -0000 I think the default behavior of session reset and its effects that scale fr= om unpleasant to disastrous, are one of the main reasons why we are having = this discussion in a first place, so while we are on it we might as well tr= y to avoid it by all means possible.=20 =20 adam > -----Original Message----- > From: Smith, Donald [mailto:Donald.Smith@CenturyLink.com] > Sent: Friday, May 23, 2014 7:09 PM > To: Shyam Sethuram; Vitkovsk=FD Adam > Cc: idr@ietf. org > Subject: RE: [Idr] draft-ietf-idr-error-handling-08 >=20 > I would totally disagree. Despite it's dynamic nature peering routes don'= t > change (completely) nearly as often as people seem to think. Thus the who= le > concept of GR. Add to that the fact that ipv4 is "exhausted" churn isn't = as > constant as people seem to believe. We need bgp to "heal" the network > when one link goes down but if it does NOT the worse that happens is it > doesn't self heal for the portion that is broken. A reset kills ALL the r= outes > between bgp speakers not just the broken link. >=20 > You can't amputate the leg to save the foot. You can amputate the foot t= o > save the leg. >=20 >=20 >=20 > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@centurylink.com >=20 >=20 >=20 > From: Idr [idr-bounces@ietf.org] on behalf of Shyam Sethuram > [shyam.ioml@gmail.com] > Sent: Thursday, May 22, 2014 4:54 PM > To: Vitkovsk=FD Adam > Cc: idr@ietf. org > Subject: Re: [Idr] draft-ietf-idr-error-handling-08 >=20 >=20 > I'd say 'lost-NLRI' is worse than session reset. You end up with stale ro= utes > (forwarding to invalid nexthop, importing to the wrong VRF, etc). > IMO if you can't successfully parse a full set of NLRIs, then session res= et > would be the better. >=20 >=20 > shyam >=20 >=20 >=20 > On Thu, May 22, 2014 at 1:42 PM, Vitkovsk=FD Adam > wrote: >=20 > I agree with Chris on this one, > It essentially boils down to whether lost-NRLI (as defined by Chris) is w= orse > than session reset. > My opinion is that session reset is worse. >=20 >=20 > adam > > -----Original Message----- > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Chris Hall > > Sent: Wednesday, May 14, 2014 2:15 PM > > To: 'idr@ietf. org' > > Subject: Re: [Idr] draft-ietf-idr-error-handling-08 > > > > Thomas Mangin wrote (on Wed 14-May-2014 at 10:24 +0100): > > .... > > > >> There are any number of heuristics that may be applied to this > > > >> problem. It would be helpful if, in practice, the vast majority o= f > > > >> implementations only ever send one set of NLRI per message. It > > > >> helps a bit if, in practice, MP_xx_REACH attributes only appear in > > > >> messages where both the Withdraw Routes and NLRI parts are empty. > > > >> Does anybody know if either of these is the case ? > > > > > > I (strongly) believe these to be common practice. I'm confident of > > > > it for the code base I've currently got access to, but can't speak > > > > authoritatively for others of course. > > > > Maybe other folks will chime in. > > > > > I know I never give this a thought. Chris, could you please elaborate > > > on why you seen this behaviour as advisable ? > > > > OK... you asked, so here goes... > > > > ...in the following: "MP_xx_NLRI" means one or both of MP_REACH_NLRI > > and MP_UNREACH_NLRI attributes; Body-NLRI refers to one or both of the > > Withdrawn Routes and NLRI sections of the UPDATE message -- the NLRI > > outside the attributes; a "set of NLRI" refers to any one of the MP_xx_= NLRI > > and Body-NLRI; and "NLRI" refers to any or all sets of NLRI in an UPDAT= E > > message. > > > > ...and this is my understanding of the problem... > > > > ...(1) for treat-as-withdraw to be "safe" (or as safe as possible) it i= s > essential > > that *all* NLRI in a broken update can be recovered. For if not, then = treat- > > as-withdraw is "incomplete", and leaves the receiver with out-of-date > routes > > in its hands, whose value is (to say the least) indeterminate. > > > > ...(2) the standard(s) allow for an UPDATE to contain between 1 and 4 s= ets > of > > NLRI. > > > > ...(3) depending on how broken the message is, there may be 0, 1 or 2 > > MP_xx_NLRI attributes buried somewhere in the rubble, and the receiver > > cannot tell how much has been lost -- the lost-NLRI. If there are no B= ody- > > NLRI, then the receiver may assume that there are 1 or 2 lost-NLRI. > > > > ...(4) if the sender follows the MP_xx_NLRI first rule, they sit on top= of the > > rubble and can be recovered. This is a change in the standard which on= e > > hopes will be implemented and deployed in some time. But in any case, > the > > receiver has no way of telling whether the sender intends to follow the > rule > > (or has succeeded !). So, if the receiver does not find MP_xx_NLRI, it= may > > have to assume the worst. > > > > ...(5) if lost-NLRI are a problem, or a problem worse than session-rese= t, > then > > the receiver appears to be in the unenviable position of having to bala= nce > > the risk/cost of an "incomplete" > > treat-as-withdraw against the benefit of avoiding (the dreaded) session= - > > reset. > > > > ...(6) if some/many/most/all lost-NLRI are worse than session-reset, th= en > > when can treat-as-withdraw be used ? > > > > At this point I go and hide under my desk. > > > > But, if in practice an UPDATE only ever contains 1 set of NLRI, then my > > descent into a paranoid, quivering wreck stops at step 2. Hurrah ! > > > > This is slightly stricter than it needs to be: there is no problem with= both > sets > > of body-NLRI appearing together. > > > > Now, you can argue that the only thing a receiver *can* do is to treat-= as- > > withdraw on the basis of the NLRI it can see, and not worry about thing= s it > > cannot see -- so that's what it *ought* to do. As a practical matter, = errors > are > > rare... errors which result in lost-NLRI are rarer still... the result = is probably > > not as bad as session-reset... and the operator should be got out of be= d to > > deal with the root-cause pretty sharpish, so any bad effects will be > > temporary... and in any case treat-as-withdraw is not a perfect work- > around, > > just the best we have. Trying to decide when it is more or less likely= that > > there are lost-NLRI -- searching through the rubble for possible surviv= ors -- > > looks like a tricky problem, and best avoided. > > > > If, de facto, the receiver can assume that messages contain either body= - > NLRI > > or just one MP_xx_NLRI attribute, then what the receiver > > *can* do doesn't change, but what it *ought* to do is less problematic,= and > > the rationale requires much, much less hand waving. > > > > It's not necessary for absolutely every sender to be absolutely guarant= eed > to > > follow this (post hoc) rule. For the minority that don't work this way= , the > > hand waving argument may be deployed. But the smaller that minority is= , > > the less vigorous the hand waving has to be to make the point. > > > > For completeness, note that the MP_xx_NLRI at the front rule is > orthogonal > > to this. Senders which follow the rule are less likely to generate a b= roken > > UPDATE from which the NLRI cannot be recovered. The rule is not releva= nt > > to what the receiver does with the UPDATE. > > > > Chris > > > > > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri May 23 15:18:36 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E9D1A0119 for ; Fri, 23 May 2014 15:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26n565yKmuz7 for ; Fri, 23 May 2014 15:18:33 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF6081A0115 for ; Fri, 23 May 2014 15:18:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BE79EC26A; Fri, 23 May 2014 18:18:31 -0400 (EDT) Date: Fri, 23 May 2014 18:18:31 -0400 From: Jeffrey Haas To: Vitkovsk? Adam Message-ID: <20140523221831.GD561@pfrc> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Gz0RepDOoLi7IFGX5StbkMmlcAM Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 22:18:34 -0000 On Fri, May 23, 2014 at 09:27:02PM +0000, Vitkovsk? Adam wrote: > I think the default behavior of session reset and its effects that scale from unpleasant to disastrous, are one of the main reasons why we are having this discussion in a first place, so while we are on it we might as well try to avoid it by all means possible. > The level of disaster is a matter of perspective. If you're the ISP in question, perhaps you think keeping the session up is the right thing to do. If you're a SP that's multiple AS hops away, and stale state creeps into the routing system because we stopped resetting sessions when known garbage has hit routing, then your customers may suffer from effectively persistent blackholes until you figure out what AS has the toxic route and do an AS-map to depref routes that go through them. Today, our evils are either local reset which impact SPs multiple hops away but at least take potentially bad stuff out of the system or our new proposal which is to hope we did the right thing and flag it adminsitratively. Only history will show whether this was a good idea or not. Meanwhile, it makes the customers happier. -- Jeff From nobody Fri May 23 16:43:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD9B1A0239 for ; Fri, 23 May 2014 16:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7jyu8nMAEvF for ; Fri, 23 May 2014 16:43:20 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305751A01C2 for ; Fri, 23 May 2014 16:43:20 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id uy17so1268719igb.11 for ; Fri, 23 May 2014 16:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NmNyLfKcPLW4O3GOs5otXk1AylN6YSwkgjxR44t7vdY=; b=UtXjfpk3QXtPfZZHEPC11O1DuOHM54fjkpDYZ8uYZTX3QFitU5zHMhjh6oXPbj/9Lf LcYJJNPBYfv4rgfEo63een5K/7sxJ9mQ2IPmLRsQLMUnUDmdnrC29EBJMtSOQ7yMMhpm 8xzPf7upX4FcRmtJmBLVG9F6HDBT3K9CmJiyBUuOiYWgjjVQrELMGqaal6bvfznR1h9U j+NzKu3zDYjQ56tfSN9JKvutok/PyMTX+K0p39JQJDTnlkkznE4so/l3qE0mIqfzVES8 LcXaKVuBFUts4nGg5NxWJwzgnJEb46gdusxazH8Hs0nc+zj/9+CGLuCE3vDIEiojxg2f Nw8w== MIME-Version: 1.0 X-Received: by 10.50.62.51 with SMTP id v19mr8257315igr.21.1400888598093; Fri, 23 May 2014 16:43:18 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 23 May 2014 16:43:17 -0700 (PDT) In-Reply-To: <20140523221831.GD561@pfrc> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> Date: Sat, 24 May 2014 01:43:17 +0200 X-Google-Sender-Auth: UxoGm_xKdRn2QFiJD1vF88BqVDE Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/eMioAmZUCtyssD4M9fl8CkWM6eM Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 23:43:21 -0000 > The level of disaster is a matter of perspective. If you're the ISP in > question, perhaps you think keeping the session up is the right thing to do. Really ? Let's not forget about history which brought us here. It all started when there were a few big SPs who's L3VPN customers suffered domain wide outages due to some vendor bugs modulo weak BGP design of the network. Indeed in L2/L3VPNs especially when your site is single homed some junk injected by another VPN site may go through PE and impact the entire service (often via RRs). In those cases it is clear that resetting the session is disaster and work has started what can we do about it. However the proposed solution spreaded IMHO well too far, by becoming SAFI agnostic. Correctly engineered IP BGP ISP network never has single path for Internet destination either at all BGP speakers or at RRs. Moreover it is very good practice to have RRs running different BGP implementations. So session reset when applied with GR (for data plane protection) is a good way to keep IPv4 or IPv6 routing healthy. It heals via selection of new BGP path and control plane and forwarding state gets updated accordingly locally to a given AS. If anything more work should be prioritized on helping troubleshooting the reason for session reset by BGP Diagnostic messages. Now because L3VPN users are carried on single engine planes and when that one goes down they all fall - we are proposing to allow Internet users which fly on multi-engine machines to continue to fly when some parts of the plane brake. Sure if this is optional transitive attribute we could perhaps compare it to failure of entertainment system on board, but going further and ignoring number of much more serious red lights in the cockpit I guess is a bit too far. Cheers, R. From nobody Sat May 24 07:30:03 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6BE1A01AF for ; Sat, 24 May 2014 07:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw9LRfKMsFKq for ; Sat, 24 May 2014 07:30:01 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6682C1A0318 for ; Sat, 24 May 2014 07:30:01 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2EBF7C251; Sat, 24 May 2014 10:29:59 -0400 (EDT) Date: Sat, 24 May 2014 10:29:59 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140524142959.GE561@pfrc> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hQ8FkLyV5dtDH2w8SrJp9-LGOBI Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 14:30:02 -0000 On Sat, May 24, 2014 at 01:43:17AM +0200, Robert Raszuk wrote: > > The level of disaster is a matter of perspective. If you're the ISP in > > question, perhaps you think keeping the session up is the right thing to do. > > Really ? > > Let's not forget about history which brought us here. > > It all started when there were a few big SPs who's L3VPN customers > suffered domain wide outages due to some vendor bugs modulo weak BGP > design of the network. Yeah, we're all intimately aware of the fun from attr-128. That specific incident is worth its own cautionary I-D, I think. > If anything more work should be prioritized on helping troubleshooting > the reason for session reset by BGP Diagnostic messages. Issues found locally are obviously something of concern. My bigger concern is that our "treat as withdraw" feature relies on correctly parsing NLRI among the thing with problems. We already have problems with BGP's stateful nature not being executed correctly leaving stale routes in the system even without this particular implementation. Were it a viable feature, "BGP traceroute" is probably the better diagnostic feature for some such issues. SPs I've discussed this idea with are generally not receptive to it. -- Jeff From nobody Sat May 24 07:45:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A801A031D for ; Sat, 24 May 2014 07:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im9zRrqeiKln for ; Sat, 24 May 2014 07:45:13 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE861A0318 for ; Sat, 24 May 2014 07:45:13 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id at1so6167514iec.15 for ; Sat, 24 May 2014 07:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/XXM1iyOo9wbiNjjdieY45iixJhDM3hjMagp7ZU7VKs=; b=uFG3xxSlqLLf1doib+qW4eILId90eI4qrtdLyAmIhx9oOmQvwhjMyC2Mq9mbwdx4Wv iU3sbdu1NR9wvhO9zIy+8nP+T6aU7oqOnDi6BX9W1twqOhMsh3z+LXqlaO7D3zjkKEi6 oKHUmzRZn81Wy1dUxNkzVSG/gdriBm5Lx9QoqjRFqvzKRhmBXg4pI6YmVAFpX4AMr/J8 gv8HIFGZ/CfgSzSim+gI7VkJ9Ci3ph5pfQYBCGiW145Kc5jtUp+0UCISg+yZYEfnrsYL rh/6fB2jXJZEYYKedOVFHiF8SOHsOyx5tixlOpkQPApbXMuXyNolOmbgpQ7kY2NzaR4G gasQ== MIME-Version: 1.0 X-Received: by 10.42.52.199 with SMTP id k7mr11497641icg.4.1400942711291; Sat, 24 May 2014 07:45:11 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Sat, 24 May 2014 07:45:11 -0700 (PDT) In-Reply-To: <20140524142959.GE561@pfrc> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> <20140524142959.GE561@pfrc> Date: Sat, 24 May 2014 16:45:11 +0200 X-Google-Sender-Auth: MumhiSXcoD0FS1y8mb-tvtBuWI0 Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/JVCJ6mjKh_Ygy98LkXUbhMovHYc Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 14:45:14 -0000 > My bigger concern > is that our "treat as withdraw" feature relies on correctly parsing NLRI > among the thing with problems. True. However let me restate my bigger concern with providing an example. The error handling as defined today is SAFI independent. Moreover it is implemented (at least in some BGP code basis) as AF-independent enhancement. For SAFI 128 in the SP core I guess this may be a brilliant solution. However for PE-CE link running BGP SAFI 1 to exchange few routes it should not be used at all in order to detect any trash when it tries to enter the BGP control plane as early as possible resulting in such specific VPN site to be brought down till NOC figures out the problem (modulo auto restart knob we all have). Same for ISP Internet v4/v6 where one has good BGP peerings design which result in multiple paths to any BGP destination. Unfortunately such option AFAIK is not possible to be enabled on a per AF or per peer basis in the new error handling spec. Thx, R. From nobody Mon May 26 01:18:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF741A004C for ; Mon, 26 May 2014 01:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lno-IIAhz4_j for ; Mon, 26 May 2014 01:18:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688781A004A for ; Mon, 26 May 2014 01:18:18 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id F3C623241C3; Mon, 26 May 2014 10:18:11 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D916C238062; Mon, 26 May 2014 10:18:11 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 26 May 2014 10:18:11 +0200 From: To: Robert Raszuk , "idr@ietf. org" Thread-Topic: [Idr] draft-ietf-idr-error-handling-08 Thread-Index: AQHPbwtijIW44tHLwk+T170Dz/t/4JtAMvMAgAAvwgCADSCQgIAAJNkAgADLIIaAACidAIAADmKAgAAXr4CAAPe+gIAABD+AgALR0yA= Date: Mon, 26 May 2014 08:18:10 +0000 Message-ID: <22974_1401092291_5382F8C3_22974_1226_1_53C29892C857584299CBF5D05346208A0714D15F@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> <20140524142959.GE561@pfrc> 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.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.13.75120 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/w3VotH8BCKymTFzrU-sj6R2uqxk Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 08:18:21 -0000 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk > Sent= : Saturday, May 24, 2014 4:45 PM >=20 > > My bigger concern > > is that our "treat as withdraw" feature relies on correctly parsing > > NLRI among the thing with problems. >=20 > True. However let me restate my bigger concern with providing an example. >=20 > The error handling as defined today is SAFI independent. Moreover it is > implemented (at least in some BGP code basis) as AF-independent > enhancement. >=20 > For SAFI 128 in the SP core I guess this may be a brilliant solution. > However for PE-CE link running BGP SAFI 1 to exchange few routes it should > not be used at all in order to detect any trash when it tries to enter th= e BGP > control plane as early as possible resulting in such specific VPN site to= be > brought down till NOC figures out the problem (modulo auto restart knob we > all have). I tend to agree with Robert that the requirement in term of level of reacti= on may be depend upon many parameters, such as the type of session (eBGP, i= BGP client, iBGP), the number of (usufull/best) routes learnt over that ses= sion, the recent history of failures (from "I don't remember any serious on= e" to "we've have two majors failures in 2 months")...=20 However adding such distinction increase the amount of complexity and bug, = while we need a robust error handling mechanism. IMO draft-ietf-idr-error-handling-08 is a good start that needs to be shipp= ed. We probably need more experience with it, to better handle the tradeoff= s. =20 > Same for ISP Internet v4/v6 where one has good BGP peerings design which > result in multiple paths to any BGP destination. My concern is not with the failure of a single BGP session, which indeed, i= f important, will be redundant. My concern is that a single error can generate multiple failures and kill a= ll redundancy. In multiple major events, the error was triggered by an attr= ibute set by the originator/destination. Hence this attribute is attached t= o all routes to that destination. There is no redundant path not having thi= s (perceived) error. [...] =20 > So session reset when applied with GR (for data plane protection) is a go= od way to keep IPv4 or IPv6 routing healthy. I guess you mean :s/GR/persistence ;-) because with GR, the restarted sess= ion will typically hit the exact same error. =20 > Unfortunately such option AFAIK is not possible to be enabled on a per AF= or > per peer basis in the new error handling spec. >=20 > Thx, > R. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon May 26 03:18:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11D01A00C6 for ; Mon, 26 May 2014 03:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odnUY3xUmQQt for ; Mon, 26 May 2014 03:18:54 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24081A00BE for ; Mon, 26 May 2014 03:18:53 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id rp18so5974362iec.12 for ; Mon, 26 May 2014 03:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PU8CS4GOiXF0JqsKDdpyoX2iL5KHd1eocyWfyG1AU8w=; b=urvYfhuwX4ObqlHKDvFMBSsJJYtrNTMWvhrRtUBG4pvkXTn7SuJRdlNA6dGxf8k1Oq H0Qx4jJ14K9pmRpRE1gTMkbPCZTNXujlMYsEX1fnLkLJc1spjDDk2or2LXI9J1rMKqi4 vmLfiYpgh2FaT9pNtSrvFU4XXpX8i/hPa5yArzTMCRMfQ3uC6/qf68zhQeB6JKIcyojL TSFiSCz55JNFtq10zQq8jIje/tRJO4ojMcndPPn1bPdBGRv6BotepDNVpzxfgIAUS9Lg rP5H7c1N/eANJHlw/zyM5Be8BX59w3BxFLzNFDMRzBwnf/jlGAxENy/00OwLhvcQBW+F GODg== MIME-Version: 1.0 X-Received: by 10.42.52.199 with SMTP id k7mr21588518icg.4.1401099531027; Mon, 26 May 2014 03:18:51 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 26 May 2014 03:18:50 -0700 (PDT) In-Reply-To: <22974_1401092291_5382F8C3_22974_1226_1_53C29892C857584299CBF5D05346208A0714D15F@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> <20140524142959.GE561@pfrc> <22974_1401092291_5382F8C3_22974_1226_1_53C29892C857584299CBF5D05346208A0714D15F@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Mon, 26 May 2014 12:18:50 +0200 X-Google-Sender-Auth: aP-cSaaEaMV5ycCwEjz8Woa8Y4E Message-ID: From: Robert Raszuk To: Bruno Decraene Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/6cZ_L2hG67PMhTLMt6LqxWHe0OA Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 10:18:54 -0000 Hi Bruno, > I tend to agree with Robert that the requirement in term of level of > reaction may be depend upon many parameters, such as the type > of session (eBGP, iBGP client, iBGP), the number of (usufull/best) > routes learnt over that session, the recent history of failures (from > "I don't remember any serious one" to "we've have two majors > failures in 2 months")... > However adding such distinction increase the amount of > complexity and bug, while we need a robust error handling > mechanism. Therefor I specifically listed IMO the most important one - per neighbor SAFI based . >> Same for ISP Internet v4/v6 where one has good BGP peerings design >> which result in multiple paths to any BGP destination. > > My concern is not with the failure of a single BGP session, which indeed, > if important, will be redundant. But current draft does not have a way to allow for such reset upon even a single error. > My concern is that a single error can generate multiple failures and > kill all redundancy. In multiple major events, the error was triggered > by an attribute set by the originator/destination. Hence this attribute > is attached to all routes to that destination. There is no redundant > path not having this (perceived) error. If malformed attribute made it to some hops away that means that BGP implementations on the way did not consider it as fatal error to reset the session. So the fact that your BGP speaker(s) crashed is a sign of bad design of the network element when traditionally a router/switch has only a single control plane (single BGP/IGP implementation). That model as proven fragile hopefully with new architectures will be changed to allow multiple redundant control planes driving forwarding of any network element. To some extend good networks already have vendor redundancy today, but that is rather expensive solution. Alternatively services like IPv4 lookup could be processed in DCs allowing for much easier and cheaper redundancy. >> So session reset when applied with GR (for data plane protection) is a good way to keep IPv4 or IPv6 routing healthy. > I guess you mean :s/GR/persistence ;-) because with GR, the restarted session will typically hit the exact same error. Nope. I meant only GR. And GR is not to wait for restart ... GR would be to continue forwarding till new best paths are computed/received. Best, R. From nobody Mon May 26 09:21:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD581A01D1 for ; Mon, 26 May 2014 09:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH4Scr5_XTzT for ; Mon, 26 May 2014 09:20:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD6D1A01BF for ; Mon, 26 May 2014 09:20:51 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id F0F7118C247; Mon, 26 May 2014 18:20:46 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D57CF238089; Mon, 26 May 2014 18:20:46 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 26 May 2014 18:20:46 +0200 From: To: Robert Raszuk Thread-Topic: [Idr] draft-ietf-idr-error-handling-08 Thread-Index: AQHPeMvlL8WJyXH1oE+Bt3qIRO0IrptTBEXg Date: Mon, 26 May 2014 16:20:46 +0000 Message-ID: <22299_1401121246_538369DE_22299_5672_1_53C29892C857584299CBF5D05346208A0714D333@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> <20140524142959.GE561@pfrc> <22974_1401092291_5382F8C3_22974_1226_1_53C29892C857584299CBF5D05346208A0714D15F@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.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.5.13.75120 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/-MEA-Y55j8bZrlJuGgCPkNFLCVw Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 16:20:53 -0000 SGkgUm9iZXJ0LA0KDQo+IEZyb206IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0Bn bWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQNCj4gUmFzenVrID4gU2VudDogTW9uZGF5LCBN YXkgMjYsIDIwMTQgMTI6MTkgUE0NCj4gDQo+IEhpIEJydW5vLA0KPiANCj4gPiBJIHRlbmQgdG8g YWdyZWUgd2l0aCBSb2JlcnQgdGhhdCB0aGUgcmVxdWlyZW1lbnQgaW4gdGVybSBvZiBsZXZlbCBv Zg0KPiA+IHJlYWN0aW9uIG1heSBiZSBkZXBlbmQgdXBvbiBtYW55IHBhcmFtZXRlcnMsIHN1Y2gg YXMgdGhlIHR5cGUgb2YNCj4gPiBzZXNzaW9uIChlQkdQLCBpQkdQIGNsaWVudCwgaUJHUCksIHRo ZSBudW1iZXIgb2YgKHVzdWZ1bGwvYmVzdCkgcm91dGVzDQo+ID4gbGVhcm50IG92ZXIgdGhhdCBz ZXNzaW9uLCB0aGUgcmVjZW50IGhpc3Rvcnkgb2YgZmFpbHVyZXMgKGZyb20gIkkNCj4gPiBkb24n dCByZW1lbWJlciBhbnkgc2VyaW91cyBvbmUiIHRvICJ3ZSd2ZSBoYXZlIHR3byBtYWpvcnMgZmFp bHVyZXMgaW4NCj4gPiAyIG1vbnRocyIpLi4uDQo+ID4gSG93ZXZlciBhZGRpbmcgc3VjaCBkaXN0 aW5jdGlvbiBpbmNyZWFzZSB0aGUgYW1vdW50IG9mIGNvbXBsZXhpdHkgYW5kDQo+ID4gYnVnLCB3 aGlsZSB3ZSBuZWVkIGEgcm9idXN0IGVycm9yIGhhbmRsaW5nIG1lY2hhbmlzbS4NCj4gDQo+IFRo ZXJlZm9yIEkgc3BlY2lmaWNhbGx5IGxpc3RlZCBJTU8gdGhlIG1vc3QgaW1wb3J0YW50IG9uZSAt IHBlciBuZWlnaGJvciBTQUZJDQo+IGJhc2VkIC4NCg0KQUZJL1NBRkkgaXMgaW5kZWVkIGEgdmFs aWQgY3JpdGVyaWEgYnV0IG9uIG15IHNpZGUsIGlmIHdlIGhhZCBtdWx0aXBsZSBsZXZlbCBvZiBl cnJvciBoYW5kbGluZyAod2hpY2ggSSdtIG5vdCBhc2tpbmcgZm9yKSBJJ2QgcmF0aGVyIGxlYXZl IGl0IHRvIGxvY2FsIGNvbmZpZ3VyYXRpb24gZm9yIGZsZXhpYmlsaXR5IChhbmQgYmVjYXVzZSBJ IHdvdWxkIG5vdCBleHBlY3Qgcm91Z2ggY29uc2Vuc3VzKS4gDQogDQo+ID4+IFNhbWUgZm9yIElT UCBJbnRlcm5ldCB2NC92NiB3aGVyZSBvbmUgaGFzIGdvb2QgQkdQIHBlZXJpbmdzIGRlc2lnbg0K PiA+PiB3aGljaCByZXN1bHQgaW4gbXVsdGlwbGUgcGF0aHMgdG8gYW55IEJHUCBkZXN0aW5hdGlv bi4NCj4gPg0KPiA+IE15IGNvbmNlcm4gaXMgbm90IHdpdGggdGhlIGZhaWx1cmUgb2YgYSBzaW5n bGUgQkdQIHNlc3Npb24sIHdoaWNoDQo+ID4gaW5kZWVkLCBpZiBpbXBvcnRhbnQsIHdpbGwgYmUg cmVkdW5kYW50Lg0KPiANCj4gQnV0IGN1cnJlbnQgZHJhZnQgZG9lcyBub3QgaGF2ZSBhIHdheSB0 byBhbGxvdyBmb3Igc3VjaCByZXNldCB1cG9uIGV2ZW4gYQ0KPiBzaW5nbGUgZXJyb3IuDQoNCkkg Z3Vlc3MgdGhlIG5ldyBiZWhhdmlvciBjb3VsZCBiZSBlbmFibGVkL2Rpc2FibGVkIHRocm91Z2gg YSBsb2NhbCBrbm9iLiBIb3dldmVyIElNTyB0aGUgbmV3IGJlaGF2aW9yIGlzIGEgbmVlZGVkIGlt cHJvdmVtZW50LCBzbyBJIGRvbid0IHNlZSB3aHkgaXQgc2hvdWxkIG5vdCBiZSBlbmFibGVkIChh c3N1bWluZyBsb2dzIGFyZSBub3cgbW9uaXRvcmVkIGZvciBlcnJvcnMgYXQgdGhlIHVwZGF0ZSBs ZXZlbCwgYW5kIG5vdCBvbmx5IGF0IHRoZSBzZXNzaW9uIGxldmVsKQ0KDQogPiA+IE15IGNvbmNl cm4gaXMgdGhhdCBhIHNpbmdsZSBlcnJvciBjYW4gZ2VuZXJhdGUgbXVsdGlwbGUgZmFpbHVyZXMg YW5kDQo+ID4ga2lsbCBhbGwgcmVkdW5kYW5jeS4gSW4gbXVsdGlwbGUgbWFqb3IgZXZlbnRzLCB0 aGUgZXJyb3Igd2FzIHRyaWdnZXJlZA0KPiA+IGJ5IGFuIGF0dHJpYnV0ZSBzZXQgYnkgdGhlIG9y aWdpbmF0b3IvZGVzdGluYXRpb24uIEhlbmNlIHRoaXMNCj4gPiBhdHRyaWJ1dGUgaXMgYXR0YWNo ZWQgdG8gYWxsIHJvdXRlcyB0byB0aGF0IGRlc3RpbmF0aW9uLiBUaGVyZSBpcyBubw0KPiA+IHJl ZHVuZGFudCBwYXRoIG5vdCBoYXZpbmcgdGhpcyAocGVyY2VpdmVkKSBlcnJvci4NCj4gDQo+IElm IG1hbGZvcm1lZCBhdHRyaWJ1dGUgbWFkZSBpdCB0byBzb21lIGhvcHMgYXdheSB0aGF0IG1lYW5z IHRoYXQgQkdQDQo+IGltcGxlbWVudGF0aW9ucyBvbiB0aGUgd2F5IGRpZCBub3QgY29uc2lkZXIg aXQgYXMgZmF0YWwgZXJyb3IgdG8gcmVzZXQgdGhlDQo+IHNlc3Npb24uDQoNClllcy4gRXZlbnR1 YWxseSB0aGVyZSBhcmUgdGhlIG9uZSB3aGljaCBhcmUgd3JvbmcuIEFuZCB3ZSBkb24ndCBuZWVk IG1hbnkgaG9wcyB0byBoYXZlIGEgc2lnbmlmaWNhbnQgbXVsdGlwbGllciBlZmZlY3QuDQoNCj4g U28gdGhlIGZhY3QgdGhhdCB5b3VyIEJHUCBzcGVha2VyKHMpIGNyYXNoZWQgaXMgYSBzaWduIG9m IGJhZCBkZXNpZ24gb2YgdGhlDQo+IG5ldHdvcmsgZWxlbWVudCB3aGVuIHRyYWRpdGlvbmFsbHkg YSByb3V0ZXIvc3dpdGNoIGhhcyBvbmx5IGEgc2luZ2xlIGNvbnRyb2wNCj4gcGxhbmUgKHNpbmds ZSBCR1AvSUdQIGltcGxlbWVudGF0aW9uKS4gVGhhdCBtb2RlbCBhcyBwcm92ZW4gZnJhZ2lsZQ0K PiBob3BlZnVsbHkgd2l0aCBuZXcgYXJjaGl0ZWN0dXJlcyB3aWxsIGJlIGNoYW5nZWQgdG8gYWxs b3cgbXVsdGlwbGUgcmVkdW5kYW50DQo+IGNvbnRyb2wgcGxhbmVzIGRyaXZpbmcgZm9yd2FyZGlu ZyBvZiBhbnkgbmV0d29yayBlbGVtZW50LiBUbyBzb21lIGV4dGVuZA0KPiBnb29kIG5ldHdvcmtz IGFscmVhZHkgaGF2ZSB2ZW5kb3IgcmVkdW5kYW5jeSB0b2RheSwgYnV0IHRoYXQgaXMgcmF0aGVy DQo+IGV4cGVuc2l2ZSBzb2x1dGlvbi4NCg0KVGhhdCBpcyBpbmRlZWQgYSBwb3NzaWJsZSBtZWRp dW0gdGVybSBldm9sdXRpb24uIEJ1dCBpbiBhZGRpdGlvbiB0byBtdWx0aXBsZSBpbXBsZW1lbnRh dGlvbnMgdG8gaGFuZGxlIGJ1Z3MsIHlvdSBtYXkgbmVlZCBtdWx0aXBsZSBwcm90b2NvbHMgdG8g aGFuZGxlIGVycm9yIGluIHNwZWMuIEFuZCBpdCdzIG5vdCBhIGxvY2FsIG9ubHkgY29uc2lkZXJh dGlvbiBhcyBpdCBtYXkgYmUgeW91ciBwZWVyIHdoaWNoIGhhdmUgaW5zZXJ0ZWQgdGhlIGVycm9y IChlLmcuIGV4dGVuZCBsZW5ndGggaXNzdWUpIHNvIHlvdSBuZWVkIHBhcmFsbGVsIHJlZHVuZGFu dCBzZXNzaW9ucyBiZXR3ZWVuIEJHUCBzcGVha2Vycy4NCg0KUmVnYXJkbGVzcywgZHJhZnQtaWV0 Zi1pZHItZXJyb3ItaGFuZGxpbmcgaXMgcmVxdWlyZWQgaW4gdGhlIHNob3J0IHRlcm0gdG8gaW5j cmVhc2UgQkdQIHNlc3Npb24gcm9idXN0bmVzcy4NCiANCj4gQWx0ZXJuYXRpdmVseSBzZXJ2aWNl cyBsaWtlIElQdjQgbG9va3VwIGNvdWxkIGJlIHByb2Nlc3NlZCBpbiBEQ3MgYWxsb3dpbmcgZm9y DQo+IG11Y2ggZWFzaWVyIGFuZCBjaGVhcGVyIHJlZHVuZGFuY3kuDQo+IA0KPiA+PiBTbyBzZXNz aW9uIHJlc2V0IHdoZW4gYXBwbGllZCB3aXRoIEdSIChmb3IgZGF0YSBwbGFuZSBwcm90ZWN0aW9u KSBpcyBhDQo+IGdvb2Qgd2F5IHRvIGtlZXAgSVB2NCBvciBJUHY2IHJvdXRpbmcgaGVhbHRoeS4N Cj4gPiBJIGd1ZXNzIHlvdSBtZWFuIDpzL0dSL3BlcnNpc3RlbmNlICA7LSkgYmVjYXVzZSB3aXRo IEdSLCB0aGUgcmVzdGFydGVkDQo+IHNlc3Npb24gd2lsbCB0eXBpY2FsbHkgaGl0IHRoZSBleGFj dCBzYW1lIGVycm9yLg0KPiANCj4gTm9wZS4gSSBtZWFudCBvbmx5IEdSLiBBbmQgR1IgaXMgbm90 IHRvIHdhaXQgZm9yIHJlc3RhcnQgLi4uIEdSIHdvdWxkIGJlIHRvDQo+IGNvbnRpbnVlIGZvcndh cmRpbmcgdGlsbCBuZXcgYmVzdCBwYXRocyBhcmUgY29tcHV0ZWQvcmVjZWl2ZWQuDQo+IA0KPiBC ZXN0LA0KPiBSLg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon May 26 09:29:43 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAC41A01C5 for ; Mon, 26 May 2014 09:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKDKYvO7FBoP for ; Mon, 26 May 2014 09:29:42 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4948F1A0108 for ; Mon, 26 May 2014 09:29:42 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id hl10so184695igb.4 for ; Mon, 26 May 2014 09:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k31bEiOBATxgjQmBFbSiIKhPUa0ec6mfiuMLgvj7D0E=; b=o+H4GzRK9O5kGSMBK1XGL5CqbpTkxLeCL/9GvKHSaP4ojBov/Wse5D9i3aVWYITcRG vbqwacbH4FW775kKFHD+WrT2oVqJN47jVV0D6lJaRsi5CRZYzZUdPXnxhHFvaL2W/Gal mVn+ETnS8yj+p4072/tHMCYHvZQNSW8519gXGCQK4FULT3sj5285K/zfg83f8gZO80V6 E+LpPkbT62/jiS1iR7U5rKfOpK61gLXJJoaE2iHsiRgQJWLndL7+N/NZ3hbRKC4Jtuba AEtkRIlo9DrFy5YRJ0pOg9gu+vR7smU0OSDBhIam+OEGRnrVd3HIpUcG3ZbfBe6XMech pb3A== MIME-Version: 1.0 X-Received: by 10.42.52.199 with SMTP id k7mr23703039icg.4.1401121779223; Mon, 26 May 2014 09:29:39 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 26 May 2014 09:29:39 -0700 (PDT) In-Reply-To: <22299_1401121246_538369DE_22299_5672_1_53C29892C857584299CBF5D05346208A0714D333@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> <20140524142959.GE561@pfrc> <22974_1401092291_5382F8C3_22974_1226_1_53C29892C857584299CBF5D05346208A0714D15F@PEXCVZYM11.corporate.adroot.infra.ftgroup> <22299_1401121246_538369DE_22299_5672_1_53C29892C857584299CBF5D05346208A0714D333@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Mon, 26 May 2014 18:29:39 +0200 X-Google-Sender-Auth: 2jp3hIe-9cj5yVCSBpeSTWSl2HE Message-ID: From: Robert Raszuk To: Bruno Decraene Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/67coPHqeeCsmJaVa5O7hzKNGQsY Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 16:29:43 -0000 > AFI/SAFI is indeed a valid criteria but on my side, if we had > multiple level of error handling (which I'm not asking for) I'd > rather leave it to local configuration for flexibility (and because > I would not expect rough consensus). But that is precisely what I am after too. Not #define that this SAFI is subject or not, but a text in the draft that the error handling should be possible to be disabled/enabled on a per AFI/SAFI per peer basis. Cheers, R. From nobody Mon May 26 11:44:02 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD971A0201 for ; Mon, 26 May 2014 11:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZmiHi8Tq5Lo for ; Mon, 26 May 2014 11:43:56 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E2831A0039 for ; Mon, 26 May 2014 11:43:56 -0700 (PDT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WozsE-0001A9-4C for idr@ietf.org; Mon, 26 May 2014 18:43:50 +0000 From: "Chris Hall" To: "'idr@ietf. org'" References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> <20140524142959.GE561@pfrc> <22974_1401092291_5382F8C3_22974_1226_1_53C29892C857584299CBF5D05346208A0714D15F@PEXCVZYM11.corporate.adroot.infra.ftgroup> <22299_1401121246_538369DE_22299_5672_1_53C29892C857584299CBF5D05346208A0714D333@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Mon, 26 May 2014 19:43:45 +0100 Organization: Highwayman Message-ID: <042101cf7912$6fb3cba0$4f1b62e0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMPT2U8hNZfkQob/r9whEuUIHdu9wIXLiUiAce54KwBJce6JAHfPLiKAq/uDRIChM5DUAGPjGf1AiAbMeABbHjz7QJ58PX9AwFwMHUBGW2q9AJ1aqkBAbdIocWX868zAA== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/xsfgzaLWB4jjMaczr0TA39SU_jY Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 18:43:57 -0000 Robert Raszuk wrote (on Mon 26-May-2014 at 17:30 +0100): > Bruno Decraene wrote: > > > AFI/SAFI is indeed a valid criteria but on my side, if we had > > multiple level of error handling (which I'm not asking for) I'd > > rather leave it to local configuration for flexibility (and > > because I would not expect rough consensus). > But that is precisely what I am after too. Not #define that this > SAFI is subject or not, but a text in the draft that the error > handling should be possible to be disabled/enabled on a per > AFI/SAFI per peer basis. Which would be possible when it's clear what the AFI/SAFI was. In the (previously noted) case of: Withdrawn Routes field -- empty Attributes: ORIGIN -- some valid origin .... ) other valid stuff... .... ) ...but NOT MP_xx_NLRI -- attributes overrun NLRI field -- empty it's (ever so) slightly tricky to tell what the AFI/SAFI was :-( Unless the session carries only one AFI/SAFI, of course. Chris From nobody Mon May 26 11:54:51 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B201A0221 for ; Mon, 26 May 2014 11:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVFc02jy2sdV for ; Mon, 26 May 2014 11:54:47 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4BC1A021E for ; Mon, 26 May 2014 11:54:47 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so261060igb.2 for ; Mon, 26 May 2014 11:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GwQJ93oHBeP3vkj/CZ/U02P+orv+4CBI53DtGZxXdfY=; b=mQDF+QjryicPjeBjfnsF7QmShvPhDza5gTBx/nqruxdxealCPhnepvzCkck7EV6XcJ L9i8ddrFLLPqUda8aX3enRdowm6An4AbJE9wKVJAOQU8qbR7KuZKtofkJnFkU6Vo/e6F n2Oe1oYzYOHNUVZfkBR8SQfOdfCKeTkn3hG3OaDkOcfE8xIty6Q3y7t167Cdi3bThkg7 RO74jC8kdATaDskqMP6YFqnPitIAEmxsROKAB6bb8Gp+Vvk9/zd0A9nMJxXEFZ0TQFFN IJ30UM2UaPoqvgkKl+i3lowIb7T7pNh3jcWuuB01IED8bveiePeVHslaBYBWPbwwJbk+ NApw== MIME-Version: 1.0 X-Received: by 10.43.87.200 with SMTP id ax8mr3741401icc.97.1401130484268; Mon, 26 May 2014 11:54:44 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 26 May 2014 11:54:44 -0700 (PDT) In-Reply-To: <042101cf7912$6fb3cba0$4f1b62e0$@highwayman.com> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> <20140524142959.GE561@pfrc> <22974_1401092291_5382F8C3_22974_1226_1_53C29892C857584299CBF5D05346208A0714D15F@PEXCVZYM11.corporate.adroot.infra.ftgroup> <22299_1401121246_538369DE_22299_5672_1_53C29892C857584299CBF5D05346208A0714D333@PEXCVZYM11.corporate.adroot.infra.ftgroup> <042101cf7912$6fb3cba0$4f1b62e0$@highwayman.com> Date: Mon, 26 May 2014 20:54:44 +0200 X-Google-Sender-Auth: LiO2y2HafdBXI5ibuZR3136xG2c Message-ID: From: Robert Raszuk To: Chris Hall Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/1oVvRGllXX3XIDgkh3U0afS96VY Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 18:54:48 -0000 Hi Chris, Isn't your example subject to reset of the session regardless what AFI/SAFI it is ? The way I see attribute overrun + no parsable NLRI present is that it does not fall under current error handling draft exceptions. r. On Mon, May 26, 2014 at 8:43 PM, Chris Hall wrote: > Robert Raszuk wrote (on Mon 26-May-2014 at 17:30 +0100): >> Bruno Decraene wrote: >> >> > AFI/SAFI is indeed a valid criteria but on my side, if we had >> > multiple level of error handling (which I'm not asking for) I'd >> > rather leave it to local configuration for flexibility (and >> > because I would not expect rough consensus). > >> But that is precisely what I am after too. Not #define that this >> SAFI is subject or not, but a text in the draft that the error >> handling should be possible to be disabled/enabled on a per >> AFI/SAFI per peer basis. > > Which would be possible when it's clear what the AFI/SAFI was. In the > (previously noted) case of: > > Withdrawn Routes field -- empty > Attributes: ORIGIN -- some valid origin > .... ) other valid stuff... > .... ) ...but NOT MP_xx_NLRI > -- attributes overrun > NLRI field -- empty > > it's (ever so) slightly tricky to tell what the AFI/SAFI was :-( > Unless the session carries only one AFI/SAFI, of course. > > Chris > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon May 26 14:03:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D7E1A028F for ; Mon, 26 May 2014 14:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5vN0XVxTApW for ; Mon, 26 May 2014 14:02:56 -0700 (PDT) Received: from owa.swan.sk (owa.swan.sk [217.75.72.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268E11A028D for ; Mon, 26 May 2014 14:02:56 -0700 (PDT) From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= To: Robert Raszuk , Chris Hall Thread-Topic: [Idr] draft-ietf-idr-error-handling-08 Thread-Index: AQHPbwtk1xERpD0lLEmW7ezhqdBFfJs/rNcAgAAvwgCADOrwUIAAWnkAgAExpYCAAGdwgP//7yaAgAAXr4CAAPe+gIAABD+AgAK4iACAACG3AIAAZR8AgAACfICAACV3gIAAAxIAgAA/uwA= Date: Mon, 26 May 2014 21:02:51 +0000 Message-ID: <61DC6BC4ABA10E4489D4A73EBABAC18B011EE8FC@EX01.swan.local> References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> <20140524142959.GE561@pfrc> <22974_1401092291_5382F8C3_22974_1226_1_53C29892C857584299CBF5D05346208A0714D15F@PEXCVZYM11.corporate.adroot.infra.ftgroup> <22299_1401121246_538369DE_22299_5672_1_53C29892C857584299CBF5D05346208A0714D333@PEXCVZYM11.corporate.adroot.infra.ftgroup> <042101cf7912$6fb3cba0$4f1b62e0$@highwayman.com> In-Reply-To: Accept-Language: sk-SK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.44.10] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HLNLZBXLscv65pA9FUAjTecmdOc Cc: "idr@ietf. org" Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 21:02:58 -0000 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk > Sent: Monday, May 26, 2014 8:55 PM >=20 > Isn't your example subject to reset of the session regardless what AFI/SA= FI it > is ? The way I see attribute overrun + no parsable NLRI present is that i= t does > not fall under current error handling draft exceptions. Hello Robert, This is the case where I'd like to see more effort before giving up and res= etting the session.=20 I don't like the idea of both upstream and downstream systems suffering fro= m one misbehaving update.=20 I guess maybe after receiving such an update BGP can request a resent of al= l the NLRIs from all the AFIs/SAFIs.=20 And if it receives some meaningful information along with the garbage it ca= n compare that to the last known received update.=20 And afterwards it could only send withdraw for the damaged delta downstream= .=20 adam From nobody Tue May 27 03:36:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC121A0078 for ; Tue, 27 May 2014 03:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Udv9jVzZrLuX for ; Tue, 27 May 2014 03:36:31 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF851A0080 for ; Tue, 27 May 2014 03:36:31 -0700 (PDT) Received: from hyperion-w.halldom.com ([80.177.246.146] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WpEk5-0001F6-FY for idr@ietf.org; Tue, 27 May 2014 10:36:25 +0000 From: "Chris Hall" To: "'idr@ietf. org'" References: <05fe01cf6f6e$1f4476e0$5dcd64a0$@highwayman.com> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE229@EX01.swan.local> <68EFACB32CF4464298EA2779B058889D12493B50@PDDCWMBXEX503.ctl.intranet> <61DC6BC4ABA10E4489D4A73EBABAC18B011EE4E8@EX01.swan.local> <20140523221831.GD561@pfrc> <20140524142959.GE561@pfrc> <22974_1401092291_5382F8C3_22974_1226_1_53C29892C857584299CBF5D05346208A0714D15F@PEXCVZYM11.corporate.adroot.infra.ftgroup> <22299_1401121246_538369DE_22299_5672_1_53C29892C857584299CBF5D05346208A0714D333@PEXCVZYM11.corporate.adroot.infra.ftgroup> <0421 01cf7912$6fb3cba0$4f1b62e0$@highwayman.com> In-Reply-To: Date: Tue, 27 May 2014 11:36:26 +0100 Organization: Highwayman Message-ID: <045f01cf7997$860cc480$92264d80$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMPT2U8hNZfkQob/r9whEuUIHdu9wIXLiUiAce54KwBJce6JAHfPLiKAq/uDRIChM5DUAGPjGf1AiAbMeABbHjz7QJ58PX9AwFwMHUBGW2q9AJ1aqkBAbdIocUCdjywRAHI6/vYl9K8O/A= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/UdTXHe4EihUHj_iF0NMno7h9IA4 Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 10:36:33 -0000 Robert Raszuk wrote (on Mon 26-May-2014 at 19:55 +0100): .... > Isn't your example subject to reset of the session regardless what > AFI/SAFI it is ? The way I see attribute overrun + no parsable NLRI > present is that it does not fall under current error handling draft > exceptions. I don't know :-( My reading suggests that the default response is to be = "treat-as-withdraw". If no NLRI at all can be found, what the draft = specifies seems to hinge on the interpretation of "successfully parsed": = is parsing nothing at all trivially successful or trivially a failure ? = Some folk appear to want the session to stay up no matter what (more or = less), so it might be helpful if this was less a matter of = interpretation. Assuming that "not finding any NLRI at all" is defined/deemed to require = session-reset: what about the cases where the receiver can find *some* = NLRI, but knows it has not found *all* NLRI ? Suppose: Withdrawn Routes field -- empty Attributes: MP_UNREACH_NLRI -- some valid NLRI ORIGIN -- some valid origin .... ) other valid stuff... .... ) ...but NOT MP_REACH_NLRI -- attributes overrun NLRI field -- empty In this case it is pretty clear that there is an MP_REACH_NLRI buried in = the rubble. For this case, and other more ambiguous ones, we need to interpret: "the = entire NLRI field and/or the MP_REACH_NLRI and MP_UNREACH_NLRI = attributes need to be successfully parsed". Chris > On Mon, May 26, 2014 at 8:43 PM, Chris Hall > wrote: > > Robert Raszuk wrote (on Mon 26-May-2014 at 17:30 +0100): > >> Bruno Decraene wrote: > >> > >> > AFI/SAFI is indeed a valid criteria but on my side, if we had > >> > multiple level of error handling (which I'm not asking for) I'd > >> > rather leave it to local configuration for flexibility (and > >> > because I would not expect rough consensus). > > > >> But that is precisely what I am after too. Not #define that this > >> SAFI is subject or not, but a text in the draft that the error > >> handling should be possible to be disabled/enabled on a per > >> AFI/SAFI per peer basis. > > > > Which would be possible when it's clear what the AFI/SAFI was. In > the > > (previously noted) case of: > > > > Withdrawn Routes field -- empty > > Attributes: ORIGIN -- some valid origin > > .... ) other valid stuff... > > .... ) ...but NOT MP_xx_NLRI > > -- attributes overrun > > NLRI field -- empty > > > > it's (ever so) slightly tricky to tell what the AFI/SAFI was :-( > > Unless the session carries only one AFI/SAFI, of course. > > > > Chris > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr From nobody Tue May 27 10:20:36 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141361A04AA for ; Tue, 27 May 2014 10:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keMqU3C_BfR8 for ; Tue, 27 May 2014 10:20:21 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1F01A01D5 for ; Tue, 27 May 2014 10:20:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Tue, 27 May 2014 13:19:07 -0400 Message-ID: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01CF79AE.3D8F5DF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac95z8QWQFsTe791Q6yxUrmTxDTYYg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/J-QJYuBZtybqc51JSkdCrHZ4pHc Cc: "'John G. Scudder'" Subject: [Idr] WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:20:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BA_01CF79AE.3D8F5DF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Working Group, This is to begin a 2 week WG LC for draft-ietf-idr-bgp-gr-notification-02.txt which will end on 6/10/2014. Please put within your comments: "support" or "no-support" for WG LC. Jeff Haas comments that the most recent changes reflect implementation experience and some word smithing. There is also a minor clarification in the NOTIFICATION message with respect to including a data byte so the original reason for the event can be propagated. (See sec. 3.1 in the diff.) The abstract is below. Sue Hares ---------- Abstract: The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. ------=_NextPart_000_00BA_01CF79AE.3D8F5DF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working = Group,

 

This is = to begin a 2 week WG LC for draft-ietf-idr-bgp-gr-notification-02.txt = which will end on 6/10/2014.  Please put within your = comments:  “support” or “no-support” for WG = LC.

 

Jeff = Haas comments that the most recent changes reflect implementation = experience and some word smithing.  There is also a minor = clarification in the NOTIFICATION message with respect to including a = data byte so the original reason for the event can be propagated.  = (See sec. 3.1 in the diff.)

 

The = abstract is below.

 

Sue = Hares

 

 

----------

 

Abstract:

   The current BGP Graceful Restart = mechanism limits the usage of BGP

   Graceful Restart to BGP protocol messages = other than a BGP

   NOTIFICATION message.  This document = defines an extension to the BGP

   Graceful Restart that permits the = Graceful Restart procedures to be

   performed when the BGP speaker receives a = BGP NOTIFICATION Message.

   This document also defines a new BGP = NOTIFICATION Cease Error subcode

   to prevent BGP speakers supporting the = extension defined in this

   document from performing a Graceful = Restart.

 

 

------=_NextPart_000_00BA_01CF79AE.3D8F5DF0-- From nobody Wed May 28 04:13:53 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B09E1A0084 for ; Wed, 28 May 2014 04:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKL7KX5YFOGF for ; Wed, 28 May 2014 04:13:48 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id E81FC1A0947 for ; Wed, 28 May 2014 04:13:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 6091164218C; Wed, 28 May 2014 13:13:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hBkAU6b4PYT; Wed, 28 May 2014 13:13:26 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id DF542642186 for ; Wed, 28 May 2014 13:13:25 +0200 (CEST) Message-ID: <5385C4D5.7030703@benocs.com> Date: Wed, 28 May 2014 13:13:25 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: idr@ietf.org References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <537B01EF.1000802@benocs.com> In-Reply-To: <537B01EF.1000802@benocs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/UYSUQUvyJsXOXZhgtaPBrzyRVg0 Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 11:13:51 -0000 Hi there, while trying to implement this draft I stumbled across a point which made me think if I really understood it correctly. The sentence I stumbled across is in section 3.g. of the draft: "[...] If any other attribute appears more than once in an UPDATE message, then all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message continue to be processed." This pretty much says the same as the corresponding sentence from section 6.3 of RFC 4271 (except for the action taken): "If any attribute appears more than once in the UPDATE message, then the Error Subcode MUST be set to Malformed Attribute List." What I am asking myself (and now you) is: Does this really address *any* attribute which appears more than once, or only *recognized* attributes? Of course, my implementation could realize by the attribute's type-code that an unrecognized (most likely optional) attribute appeared more than once in an UPDATE-message. But maybe, that could be valid for that unrecognized path-attribute? So, if there is any chance of a (new) path-attribute to be allowed to appear more than once in an UPDATE-message, I would recommend to change the sentence in question to the following in the next version of this draft: "[...] If any other recognized attribute appears more than once in an UPDATE message, then all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message continue to be processed. Unrecognized attributes are still allowed to appear more than once." If this it not what is intended, then I would recommend to explicitly state that this sentence is meant for recognized as well as unrecognized attributes, so that nobody might misinterpret it (as I might have done): "[...] If any other attribute (no matter if recognized or not) appears more than once in an UPDATE message, then all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message continue to be processed. (Multiple appearances of even unrecognized attributes can be be realized by the attributes' type-codes.)" (The sentence in parentheses is just for clarification and could be removed if it is too obvious.) Deniz Am 20.05.2014 09:19, schrieb Deniz Bahadir: > I have nothing to complain or to add. > Therefore, I support this draft being the final version and becoming an > RFC. > > Thanks for the good work, > Deniz > > > Am 19.05.2014 21:51, schrieb John G. Scudder: >> There are just a few relatively small changes in this version: >> >> - Note that when MP-BGP is in use, NEXT_HOP is discretionary. >> - Better text for NLRI section (thanks to Ondrej). >> - Fix typos. >> >> With luck, we are spiraling in to a final version. >> >> Thanks, all. >> >> --John >> >> On May 19, 2014, at 3:33 PM, 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 Inter-Domain Routing Working Group >>> of the IETF. >>> >>> Title : Revised Error Handling for BGP UPDATE Messages >>> Authors : Enke Chen >>> Juniper Networks >>> Pradosh Mohapatra >>> Keyur Patel >>> Filename : draft-ietf-idr-error-handling-09.txt >>> Pages : 14 >>> Date : 2014-05-19 >>> >>> Abstract: >>> According to the base BGP specification, a BGP speaker that receives >>> an UPDATE message containing a malformed attribute is required to >>> reset the session over which the offending attribute was received. >>> This behavior is undesirable as a session reset would impact not only >>> routes with the offending attribute, but also other valid routes >>> exchanged over the session. This document partially revises the >>> error handling for UPDATE messages, and provides guidelines for the >>> authors of documents defining new attributes. Finally, it revises >>> the error handling procedures for a number of existing attributes. >>> >>> This document updates error handling for RFCs 1997, 4271, 4360, 4456, >>> 4760 and 5701. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-idr-error-handling-09 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-09 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 28 04:22:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11FE1A0955 for ; Wed, 28 May 2014 04:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfloetHGAhw9 for ; Wed, 28 May 2014 04:22:38 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id 55C6B1A095E for ; Wed, 28 May 2014 04:22:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 9CD0864218C; Wed, 28 May 2014 13:22:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLi5qEw3BUxF; Wed, 28 May 2014 13:22:18 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 3D6F4642186 for ; Wed, 28 May 2014 13:22:18 +0200 (CEST) Message-ID: <5385C6E9.7080105@benocs.com> Date: Wed, 28 May 2014 13:22:17 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: idr@ietf.org References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <537B01EF.1000802@benocs.com> <5385C4D5.7030703@benocs.com> In-Reply-To: <5385C4D5.7030703@benocs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/x8z2uDjSt1115sb1VoRzEOlj_jg Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 11:22:41 -0000 My English seems not to be the best. I should probably replace "realized" with "identified" in my proposed-sentence. I replaced it inline further down. Deniz Am 28.05.2014 13:13, schrieb Deniz Bahadir: > Hi there, > > while trying to implement this draft I stumbled across a point which > made me think if I really understood it correctly. > > > The sentence I stumbled across is in section 3.g. of the draft: > > "[...] If any other attribute appears more than once in an UPDATE > message, then all the occurrences of the attribute other than the first > one SHALL be discarded and the UPDATE message continue to be processed." > > This pretty much says the same as the corresponding sentence from > section 6.3 of RFC 4271 (except for the action taken): > > "If any attribute appears more than once in the UPDATE message, then the > Error Subcode MUST be set to Malformed Attribute List." > > > What I am asking myself (and now you) is: > Does this really address *any* attribute which appears more than once, > or only *recognized* attributes? > > > Of course, my implementation could realize by the attribute's type-code > that an unrecognized (most likely optional) attribute appeared more than > once in an UPDATE-message. But maybe, that could be valid for that > unrecognized path-attribute? > > So, if there is any chance of a (new) path-attribute to be allowed to > appear more than once in an UPDATE-message, I would recommend to change > the sentence in question to the following in the next version of this > draft: > > > "[...] If any other recognized attribute appears more than once in an > UPDATE message, then all the occurrences of the attribute other than the > first one SHALL be discarded and the UPDATE message continue to be > processed. Unrecognized attributes are still allowed to appear more than > once." > > > If this it not what is intended, then I would recommend to explicitly > state that this sentence is meant for recognized as well as unrecognized > attributes, so that nobody might misinterpret it (as I might have done): > OLD: > "[...] If any other attribute (no matter if recognized or not) appears > more than once in an UPDATE message, then all the occurrences of the > attribute other than the first one SHALL be discarded and the UPDATE > message continue to be processed. (Multiple appearances of even > unrecognized attributes can be be realized by the attributes' type-codes.)" NEW: "[...] If any other attribute (no matter if recognized or not) appears more than once in an UPDATE message, then all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message continue to be processed. (Multiple appearances of even unrecognized attributes can be be identified by the attributes' type-codes.)" > > (The sentence in parentheses is just for clarification and could be > removed if it is too obvious.) > > Deniz > > > Am 20.05.2014 09:19, schrieb Deniz Bahadir: >> I have nothing to complain or to add. >> Therefore, I support this draft being the final version and becoming an >> RFC. >> >> Thanks for the good work, >> Deniz >> >> >> Am 19.05.2014 21:51, schrieb John G. Scudder: >>> There are just a few relatively small changes in this version: >>> >>> - Note that when MP-BGP is in use, NEXT_HOP is discretionary. >>> - Better text for NLRI section (thanks to Ondrej). >>> - Fix typos. >>> >>> With luck, we are spiraling in to a final version. >>> >>> Thanks, all. >>> >>> --John >>> >>> On May 19, 2014, at 3:33 PM, 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 Inter-Domain Routing Working Group >>>> of the IETF. >>>> >>>> Title : Revised Error Handling for BGP UPDATE >>>> Messages >>>> Authors : Enke Chen >>>> Juniper Networks >>>> Pradosh Mohapatra >>>> Keyur Patel >>>> Filename : draft-ietf-idr-error-handling-09.txt >>>> Pages : 14 >>>> Date : 2014-05-19 >>>> >>>> Abstract: >>>> According to the base BGP specification, a BGP speaker that receives >>>> an UPDATE message containing a malformed attribute is required to >>>> reset the session over which the offending attribute was received. >>>> This behavior is undesirable as a session reset would impact not >>>> only >>>> routes with the offending attribute, but also other valid routes >>>> exchanged over the session. This document partially revises the >>>> error handling for UPDATE messages, and provides guidelines for the >>>> authors of documents defining new attributes. Finally, it revises >>>> the error handling procedures for a number of existing attributes. >>>> >>>> This document updates error handling for RFCs 1997, 4271, 4360, >>>> 4456, >>>> 4760 and 5701. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-idr-error-handling-09 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-09 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 28 04:45:03 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCF11A0092 for ; Wed, 28 May 2014 04:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tptb5b0X_-Zo for ; Wed, 28 May 2014 04:44:54 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56C11A00B1 for ; Wed, 28 May 2014 04:44:53 -0700 (PDT) Received: from hyperion-w.halldom.com ([80.177.246.146] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WpcHl-0001RJ-Ib for idr@ietf.org; Wed, 28 May 2014 11:44:45 +0000 From: "Chris Hall" To: "'idr wg'" References: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> In-Reply-To: <00b901cf79cf$c4a03aa0$4de0afe0$@ndzh.com> Date: Wed, 28 May 2014 12:44:47 +0100 Organization: Highwayman Message-ID: <04df01cf7a6a$3d259930$b770cb90$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHj8zmFvh1jk/WZ0RLUyz06hRSFGpsr1EIQ Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/cK7h4SswUAudJ82AYC9H82eJbDo Subject: Re: [Idr] WG LC draft-ietf-idr-bgp-gr-notificatoin-02.txt - from 5/27/14 to 6/10/14 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 11:45:00 -0000 Susan Hares wrote (on Tue 27-May-2014 at 18:19 +0100): .... > Jeff Haas comments that the most recent changes reflect > implementation experience and some word smithing. There is also a > minor clarification in the NOTIFICATION message with respect to > including a data byte so the original reason for the event can be > propagated. (See sec. 3.1 in the diff.) I discovered that draft-00 invented the 'N' bit in the "Flags for Address Family" and draft-01 un-invented it. When this goes forward as an RFC, is this (still-born) 'N' bit then forever deprecated ? [I looked at this and could not, for the life of me, remember an 'N' bit in RFC4724 :-(] I note that Section 3.1 says: "When sending a Hard Reset, the data portion of the NOTIFICATION message MUST be used to indicate the reason for the hard reset. The reason is encoded using a standard BGP Cease error subcode and MAY also include any relevant data subsequent to the subcode." which rather limits what can be indicated... if (say) an UPDATE Message Error (Code=3), Attribute Length Error (Subcode=5) is (for whatever reason) to be sent as a Hard Error, then the reason gets rather lost ? Why not treat the Hard Reset Code=6 Subcode=9 as a two octet prefix on the complete original NOTIFICATION message ? I note, in passing, that the Hard Reset is intended for consenting speakers ("Graceful Notification flag has been exchanged") but there is an absence of MUST. I assume it is deliberate that the sender of an 'N' flag does not have to receive one before it MUST follow the rules of Section 4.1 on receipt of a NOTIFICATION (other than a Hard Reset) ? (It seems that the main effect of receiving an 'N' flag is that the receiver no longer needs to suppress any urge to send a NOTIFICATION, in those cases where triggering a Graceful Restart is considered far more useful than the small amount of information a NOTIFICATION would carry.) Chris [I guess it's all too late now... but a new "Hard Error" Code (Code=7) would avoid getting tangled up with RFC4486, and could be defined to be a one octet prefix for the original NOTIFICATION ? Alternatively... the "Hard Bit" could be encoded as the MS-Bit of the Code octet ? I guess that was considered and rejected as requiring too much IANA paperwork ? Or is there an argument that (other) systems handling NOTIFICATIONs are more likely to be tolerant of new/unknown Subcodes than they are of new/unknown Codes ? In which case... the "Hard Bit" could be encoded as the MS bit of the Subcode ?] From nobody Wed May 28 06:57:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F97A1A014D for ; Wed, 28 May 2014 06:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STydeNn5W-Rt for ; Wed, 28 May 2014 06:57:48 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579661A011F for ; Wed, 28 May 2014 06:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6902; q=dns/txt; s=iport; t=1401285465; x=1402495065; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zd7klrX7QuMxqrCn+wHYniAeZ8leCiUEHiGim+HfHkI=; b=POxS4T6Eo8vcsTEFsPcaZl6znf67JjoiZBqa1m07e/ewFWO4aZF0HBpn IPL+51+k/BhnjKJhLK5lwq4J5uF9x3ie01ET7ysOlB25D7kDCegL1407O PNhkSAqsLIcXfCHbkfote2/6ZOIzhq8+3VunvKmivAg2QvvMR0+ggv3bP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgIABPqhVOtJA2N/2dsb2JhbABZgwdSUbpwhzoBgQkWdIIlAQEBAwEBAQE3NAsFCwIBCBgeECcLJQIEDgUJC4gmCAgF1lUXiTOEbDMHgyuBFQSZdYE9kWqDOA X-IronPort-AV: E=Sophos;i="4.98,928,1392163200"; d="scan'208";a="47921436" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 28 May 2014 13:57:44 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4SDvii0006330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 May 2014 13:57:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 28 May 2014 08:57:43 -0500 From: "Jakob Heitz (jheitz)" To: "" Thread-Topic: [Idr] draft-ietf-idr-error-handling-09.txt Thread-Index: AQHPemXu8TA/yWDGLUGOLwd2Eve0M5tWLS+A///XnVg= Date: Wed, 28 May 2014 13:57:43 +0000 Message-ID: <94C526C8-EFDD-411E-B879-DB2AFBB9EEDF@cisco.com> References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <537B01EF.1000802@benocs.com> <5385C4D5.7030703@benocs.com>,<5385C6E9.7080105@benocs.com> In-Reply-To: <5385C6E9.7080105@benocs.com> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Vi23Qj7UEOIgjKvsNYuKwbam3eo Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 13:57:50 -0000 We know better than to ever invent an attribute type that can appear more t= han once in an UPDATE. An UPDATE with multiple attributes of a single type = would never survive a trip through a legacy router. It is not a serious res= triction. For example, we can fit many communities into a community attribu= te. -- Jakob Heitz. > On May 28, 2014, at 4:22 AM, "Deniz Bahadir" wrote: >=20 > My English seems not to be the best. I should probably replace "realized"= with "identified" in my proposed-sentence. > I replaced it inline further down. >=20 > Deniz >=20 > Am 28.05.2014 13:13, schrieb Deniz Bahadir: >> Hi there, >>=20 >> while trying to implement this draft I stumbled across a point which >> made me think if I really understood it correctly. >>=20 >>=20 >> The sentence I stumbled across is in section 3.g. of the draft: >>=20 >> "[...] If any other attribute appears more than once in an UPDATE >> message, then all the occurrences of the attribute other than the first >> one SHALL be discarded and the UPDATE message continue to be processed." >>=20 >> This pretty much says the same as the corresponding sentence from >> section 6.3 of RFC 4271 (except for the action taken): >>=20 >> "If any attribute appears more than once in the UPDATE message, then the >> Error Subcode MUST be set to Malformed Attribute List." >>=20 >>=20 >> What I am asking myself (and now you) is: >> Does this really address *any* attribute which appears more than once, >> or only *recognized* attributes? >>=20 >>=20 >> Of course, my implementation could realize by the attribute's type-code >> that an unrecognized (most likely optional) attribute appeared more than >> once in an UPDATE-message. But maybe, that could be valid for that >> unrecognized path-attribute? >>=20 >> So, if there is any chance of a (new) path-attribute to be allowed to >> appear more than once in an UPDATE-message, I would recommend to change >> the sentence in question to the following in the next version of this >> draft: >>=20 >>=20 >> "[...] If any other recognized attribute appears more than once in an >> UPDATE message, then all the occurrences of the attribute other than the >> first one SHALL be discarded and the UPDATE message continue to be >> processed. Unrecognized attributes are still allowed to appear more than >> once." >>=20 >>=20 >> If this it not what is intended, then I would recommend to explicitly >> state that this sentence is meant for recognized as well as unrecognized >> attributes, so that nobody might misinterpret it (as I might have done): >=20 > OLD: >> "[...] If any other attribute (no matter if recognized or not) appears >> more than once in an UPDATE message, then all the occurrences of the >> attribute other than the first one SHALL be discarded and the UPDATE >> message continue to be processed. (Multiple appearances of even >> unrecognized attributes can be be realized by the attributes' type-codes= .)" >=20 > NEW: > "[...] If any other attribute (no matter if recognized or not) appears > more than once in an UPDATE message, then all the occurrences of the > attribute other than the first one SHALL be discarded and the UPDATE > message continue to be processed. (Multiple appearances of even > unrecognized attributes can be be identified by the attributes' > type-codes.)" >=20 >=20 >>=20 >> (The sentence in parentheses is just for clarification and could be >> removed if it is too obvious.) >>=20 >> Deniz >>=20 >>=20 >> Am 20.05.2014 09:19, schrieb Deniz Bahadir: >>> I have nothing to complain or to add. >>> Therefore, I support this draft being the final version and becoming an >>> RFC. >>>=20 >>> Thanks for the good work, >>> Deniz >>>=20 >>>=20 >>> Am 19.05.2014 21:51, schrieb John G. Scudder: >>>> There are just a few relatively small changes in this version: >>>>=20 >>>> - Note that when MP-BGP is in use, NEXT_HOP is discretionary. >>>> - Better text for NLRI section (thanks to Ondrej). >>>> - Fix typos. >>>>=20 >>>> With luck, we are spiraling in to a final version. >>>>=20 >>>> Thanks, all. >>>>=20 >>>> --John >>>>=20 >>>>> On May 19, 2014, at 3:33 PM, 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 Inter-Domain Routing Working Group >>>>> of the IETF. >>>>>=20 >>>>> Title : Revised Error Handling for BGP UPDATE >>>>> Messages >>>>> Authors : Enke Chen >>>>> Juniper Networks >>>>> Pradosh Mohapatra >>>>> Keyur Patel >>>>> Filename : draft-ietf-idr-error-handling-09.txt >>>>> Pages : 14 >>>>> Date : 2014-05-19 >>>>>=20 >>>>> Abstract: >>>>> According to the base BGP specification, a BGP speaker that receive= s >>>>> an UPDATE message containing a malformed attribute is required to >>>>> reset the session over which the offending attribute was received. >>>>> This behavior is undesirable as a session reset would impact not >>>>> only >>>>> routes with the offending attribute, but also other valid routes >>>>> exchanged over the session. This document partially revises the >>>>> error handling for UPDATE messages, and provides guidelines for the >>>>> authors of documents defining new attributes. Finally, it revises >>>>> the error handling procedures for a number of existing attributes. >>>>>=20 >>>>> This document updates error handling for RFCs 1997, 4271, 4360, >>>>> 4456, >>>>> 4760 and 5701. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-idr-error-handling-09 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-09 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 28 07:14:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D841A0126 for ; Wed, 28 May 2014 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-aGmBhQyazL for ; Wed, 28 May 2014 07:14:21 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id DBECC1A09AD for ; Wed, 28 May 2014 07:14:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 0D3AC642198; Wed, 28 May 2014 16:14:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVjxz5IqnzWm; Wed, 28 May 2014 16:14:07 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 00065642197 for ; Wed, 28 May 2014 16:14:06 +0200 (CEST) Message-ID: <5385EF2E.3020007@benocs.com> Date: Wed, 28 May 2014 16:14:06 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: idr@ietf.org References: <20140514233248.GD12659@localhost> In-Reply-To: <20140514233248.GD12659@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/euLXQDjZs78M_zZiHLW4zkHIkzM Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 14:14:29 -0000 Hi guys, I wanted to bring back to mind Ondrej's comments concerning section 3.c ("Attribute Flag error handling") and his comments concerning handling of errors in the Next Hop field of MP_REACH_NLRI. > 3. c. Attribute Flag error handling: > > Formulation "If any recognized attribute has Attribute Flags that > conflict with the Attribute Type Code" is IMHO a bit vague about which > flags could be in conflict with the attribute code. Optional (O) and > Transitive (T) bits clearly could, undefined bits cleary couldn't, > but i am not sure about Partial and and Extended Legth. > > (e.g. if there is 300B long AGGREGATOR with Extended Length flag, should > it be just discarded according to 6.7. based on its length, or should it > be treat-as-withdraw according by 3. c. because AGGREGATOR should not > ever have Extended Length flag set?) > > Should the zeroness of Partial (P) bit for other than optional transitive > atributes be checked? For all or just for recognized attributes? > > And what if i receive unrecognized attribute without optional flag? > That is cleary broken but not covered by the formulation from the > draft (or from the RFC 4271). > > IMHO, O bit and consistency of O-T-P bits (i.e. no partial unless > optional transitive) should be checked for all atributes, additionally > T bit should be checked for recognized attributes. EL bit should > not be checked (should be considered intependently on attribute type). > I agree with that interpretation of how attribute flags should be checked for validity. (Especially, considering the "extended length" flag as independent of the other flags and not checking that.) Still, I would like to know how current implementations handle that and if we could find a (rough) consensus about how to formulate that point so that no misinterpretation could occur. > > 4.2 Syntactic Correctness of NLRI Fields > > What about the Next Hop field in MP_REACH_NLRI? Although specifying > syntactic correctness for all possible AFIs is out of scope of the > draft, the draft could say in 4.2 how errors of the Next hop field > should be generally handled. Although the draft handles errors in > MP_REACH_NLRI by session-reset, i would suggest that errors in the Next > Hop field of MP_REACH_NLRI should be handled by treat-as-withdraw > (as long as NLRI part of MP_REACH_NLRI is parsed without errors). > Ondrej's comment concerning errors in the next-hop-field of MP_REACH_NLRI made me think about "similar actions for similar things" again. The draft suggests to use treat-as-withdraw for any kind of error in a NEXT_HOP attribute: 3.c. attribute flags error 3.d. missing well-know attribute (if not used MP_REACH_NLRI) 3.e. other errors originally resulting in session-reset To me it looks logical that errors in MP_REACH_NLRI which (only) concern the Next Hop field should be treated uniformly and therefore result in treat-as-withdraw. One could actually see this as part of clause 3.d. because the Next Hop field in MP_REACH_NLRI takes the role of the well-known attribute NEXT_HOP. Because of that I would support Ondrej's suggestions. However, that brings me to a "bonus"-question: Section 7 ("Error Handling") of RFC 4760 ("Multiprotocol Extension") states that "if the speaker determines that the attribute is incorrect, the speaker MUST delete all the BGP routes received from that neighbor whose AFI/SAFI is the same as the one carried in the incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute." When talking about "treat-as-withdraw" in the draft we are still meaning to *only* withdraw the NLRI information enclosed in the current UPDATE-message and not the ones received from earlier UPDATE-messages, correct? Therefore section 7 of RFC 4760 does not apply here --even with the above described different handling of erroneous Next Hop field in MP_REACH_NLRI-- and MAY only be used if parsing the NLRI from MP_{UN}REACH_NLRI could not be parsed successfully (as section 3.j. mentions)!? Looking forward to your comments. Deniz PS: It seems, I was a little fast in my earlier email with stating to not have any more comments for draft 09, when I still had some left for 08. :-) From nobody Wed May 28 07:26:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030801A0125 for ; Wed, 28 May 2014 07:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xvYIHWFRYZJ for ; Wed, 28 May 2014 07:26:44 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC6D1A033B for ; Wed, 28 May 2014 07:26:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id 8ACE0642198; Wed, 28 May 2014 16:26:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZp+P7Hv+VQB; Wed, 28 May 2014 16:26:36 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id 416A5642197 for ; Wed, 28 May 2014 16:26:36 +0200 (CEST) Message-ID: <5385F21B.9060001@benocs.com> Date: Wed, 28 May 2014 16:26:35 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "idr@ietf.org" References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <537B01EF.1000802@benocs.com> <5385C4D5.7030703@benocs.com>, <5385C6E9.7080105@benocs.com> <94C526C8-EFDD-411E-B879-DB2AFBB9EEDF@cisco.com> In-Reply-To: <94C526C8-EFDD-411E-B879-DB2AFBB9EEDF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ia4C8ZFhstGwRUUTyPNUsU3gdLU Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 14:26:47 -0000 > We know better than to ever invent an attribute type that can appear more than once in an UPDATE. An UPDATE with multiple attributes of a single type would never survive a trip through a legacy router. It is not a serious restriction. For example, we can fit many communities into a community attribute. > OK, than it seems correct as written in the draft. But still, does anything argue against being a little bit more explicit and change "If any other attribute appears..." to "If any other attribute (no matter if recognized or not) appears..." so that superfluous misinterpretation (as I did) can be prevented? Deniz > > >> On May 28, 2014, at 4:22 AM, "Deniz Bahadir" wrote: >> >> My English seems not to be the best. I should probably replace "realized" with "identified" in my proposed-sentence. >> I replaced it inline further down. >> >> Deniz >> >> Am 28.05.2014 13:13, schrieb Deniz Bahadir: >>> Hi there, >>> >>> while trying to implement this draft I stumbled across a point which >>> made me think if I really understood it correctly. >>> >>> >>> The sentence I stumbled across is in section 3.g. of the draft: >>> >>> "[...] If any other attribute appears more than once in an UPDATE >>> message, then all the occurrences of the attribute other than the first >>> one SHALL be discarded and the UPDATE message continue to be processed." >>> >>> This pretty much says the same as the corresponding sentence from >>> section 6.3 of RFC 4271 (except for the action taken): >>> >>> "If any attribute appears more than once in the UPDATE message, then the >>> Error Subcode MUST be set to Malformed Attribute List." >>> >>> >>> What I am asking myself (and now you) is: >>> Does this really address *any* attribute which appears more than once, >>> or only *recognized* attributes? >>> >>> >>> Of course, my implementation could realize by the attribute's type-code >>> that an unrecognized (most likely optional) attribute appeared more than >>> once in an UPDATE-message. But maybe, that could be valid for that >>> unrecognized path-attribute? >>> >>> So, if there is any chance of a (new) path-attribute to be allowed to >>> appear more than once in an UPDATE-message, I would recommend to change >>> the sentence in question to the following in the next version of this >>> draft: >>> >>> >>> "[...] If any other recognized attribute appears more than once in an >>> UPDATE message, then all the occurrences of the attribute other than the >>> first one SHALL be discarded and the UPDATE message continue to be >>> processed. Unrecognized attributes are still allowed to appear more than >>> once." >>> >>> >>> If this it not what is intended, then I would recommend to explicitly >>> state that this sentence is meant for recognized as well as unrecognized >>> attributes, so that nobody might misinterpret it (as I might have done): >> >> OLD: >>> "[...] If any other attribute (no matter if recognized or not) appears >>> more than once in an UPDATE message, then all the occurrences of the >>> attribute other than the first one SHALL be discarded and the UPDATE >>> message continue to be processed. (Multiple appearances of even >>> unrecognized attributes can be be realized by the attributes' type-codes.)" >> >> NEW: >> "[...] If any other attribute (no matter if recognized or not) appears >> more than once in an UPDATE message, then all the occurrences of the >> attribute other than the first one SHALL be discarded and the UPDATE >> message continue to be processed. (Multiple appearances of even >> unrecognized attributes can be be identified by the attributes' >> type-codes.)" >> >> >>> >>> (The sentence in parentheses is just for clarification and could be >>> removed if it is too obvious.) >>> >>> Deniz >>> >>> >>> Am 20.05.2014 09:19, schrieb Deniz Bahadir: >>>> I have nothing to complain or to add. >>>> Therefore, I support this draft being the final version and becoming an >>>> RFC. >>>> >>>> Thanks for the good work, >>>> Deniz >>>> >>>> >>>> Am 19.05.2014 21:51, schrieb John G. Scudder: >>>>> There are just a few relatively small changes in this version: >>>>> >>>>> - Note that when MP-BGP is in use, NEXT_HOP is discretionary. >>>>> - Better text for NLRI section (thanks to Ondrej). >>>>> - Fix typos. >>>>> >>>>> With luck, we are spiraling in to a final version. >>>>> >>>>> Thanks, all. >>>>> >>>>> --John >>>>> >>>>>> On May 19, 2014, at 3:33 PM, 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 Inter-Domain Routing Working Group >>>>>> of the IETF. >>>>>> >>>>>> Title : Revised Error Handling for BGP UPDATE >>>>>> Messages >>>>>> Authors : Enke Chen >>>>>> Juniper Networks >>>>>> Pradosh Mohapatra >>>>>> Keyur Patel >>>>>> Filename : draft-ietf-idr-error-handling-09.txt >>>>>> Pages : 14 >>>>>> Date : 2014-05-19 >>>>>> >>>>>> Abstract: >>>>>> According to the base BGP specification, a BGP speaker that receives >>>>>> an UPDATE message containing a malformed attribute is required to >>>>>> reset the session over which the offending attribute was received. >>>>>> This behavior is undesirable as a session reset would impact not >>>>>> only >>>>>> routes with the offending attribute, but also other valid routes >>>>>> exchanged over the session. This document partially revises the >>>>>> error handling for UPDATE messages, and provides guidelines for the >>>>>> authors of documents defining new attributes. Finally, it revises >>>>>> the error handling procedures for a number of existing attributes. >>>>>> >>>>>> This document updates error handling for RFCs 1997, 4271, 4360, >>>>>> 4456, >>>>>> 4760 and 5701. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-idr-error-handling-09 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-09 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From nobody Wed May 28 07:41:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617131A09A6 for ; Wed, 28 May 2014 07:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMv34VBJBoeA for ; Wed, 28 May 2014 07:41:15 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83591A0409 for ; Wed, 28 May 2014 07:41:14 -0700 (PDT) Received: from hyperion-w.halldom.com ([80.177.246.146] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Wpf2R-0001UK-8K for idr@ietf.org; Wed, 28 May 2014 14:41:07 +0000 From: "Chris Hall" To: References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <537B01EF.1000802@benocs.com> <5385C4D5.7030703@benocs.com> In-Reply-To: <5385C4D5.7030703@benocs.com> Date: Wed, 28 May 2014 15:41:09 +0100 Organization: Highwayman Message-ID: <050001cf7a82$e06e35d0$a14aa170$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHq8GuwBYAROfMVxoWKkdFU2NUYygIe4lDJAq1YM8UBryXGuZrrOYLw Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/J3E0WadkfnbYJgFSRNdtif2uSNc Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 14:41:16 -0000 Deniz Bahadir wrote (on Wed 28-May-2014 at 12:13 +0100): .... > while trying to implement this draft I stumbled across a point which > made me think if I really understood it correctly. > > The sentence I stumbled across is in section 3.g. of the draft: > > "[...] If any other attribute appears more than once in an UPDATE > message, then all the occurrences of the attribute other than the > first one SHALL be discarded and the UPDATE message continue to > be processed." > > This pretty much says the same as the corresponding sentence from > section 6.3 of RFC 4271 (except for the action taken): > > "If any attribute appears more than once in the UPDATE message, then > the Error Subcode MUST be set to Malformed Attribute List." Strictly between ourselves: I've wrestled with the requirement to discard second and subsequent instances of the same attribute. I confess, for the longest time I was tempted to think that treat-as-withdraw would be the better way. But I have seen the light, and I regret my previous heresy -- I repent and recant, and I am saved. The scales have dropped from my eyes: it is clear to me now that the first AS_PATH attribute in a message is blessed and anointed, but any second or subsequent one is an abomination, and should be cast into oblivion, and never spoken of again. I can see that now. > What I am asking myself (and now you) is: Does this really > address *any* attribute which appears more than once, > or only *recognized* attributes? You are right, there is a difference between casting-out repeated attributes you do recognise and casting-out ones you don't. The difference is that you are saving some down-stream BGP speaker, who does understand the attribute, from having to even look at any repeats, which (as above) are manifestly unclean. If their error-handling is not up to it, the down-stream would have session-reset, so you have done them a favour and saved them from themselves. They will thank you for it and bless you and your children too, so they will. Chris From nobody Wed May 28 12:29:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA161A068A for ; Wed, 28 May 2014 12:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLC1ha6UKTks for ; Wed, 28 May 2014 12:29:12 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB661A065F for ; Wed, 28 May 2014 12:28:48 -0700 (PDT) Received: from hyperion-w.halldom.com ([80.177.246.146] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WpjWk-0001Za-Eh for idr@ietf.org; Wed, 28 May 2014 19:28:42 +0000 From: "Chris Hall" To: References: <20140514233248.GD12659@localhost> <5385EF2E.3020007@benocs.com> In-Reply-To: <5385EF2E.3020007@benocs.com> Date: Wed, 28 May 2014 20:28:44 +0100 Organization: Highwayman Message-ID: <051401cf7aab$0d4bee30$27e3ca90$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMPT2U8hNZfkQob/r9whEuUIHdu9wG5qq6bASW9446Yv3QFkA== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/iseMdT4Qswj3P3Pxe1SEEevA2jY Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 19:29:15 -0000 Deniz Bahadir wrote (on Wed 28-May-2014 at 15:14 +0100): .... > I wanted to bring back to mind Ondrej's comments concerning section > 3.c ("Attribute Flag error handling") and his comments concerning > handling of errors in the Next Hop field of MP_REACH_NLRI. >=20 > > 3. c. Attribute Flag error handling: .... > > Should the zeroness of Partial (P) bit for other than optional > > transitive atributes be checked? For all or just for recognized > > attributes? > > > > And what if i receive unrecognized attribute without optional > > flag? That is cleary broken but not covered by the formulation > > from the draft (or from the RFC 4271). > > > > IMHO, O bit and consistency of O-T-P bits (i.e. no partial unless > > optional transitive) should be checked for all atributes, > > additionally T bit should be checked for recognized attributes. > > EL bit should not be checked (should be considered intependently > > on attribute type). > I agree with that interpretation of how attribute flags should be > checked for validity. (Especially, considering the "extended length" > flag as independent of the other flags and not checking that.) >=20 > Still, I would like to know how current implementations handle that > and if we could find a (rough) consensus about how to formulate > that point so that no misinterpretation could occur. My understanding of RFC4271 is that the "well-known" attributes are those listed at the end of the introduction to Section 5, on p25. And that all other attributes are "optional". Section 4.3 on p16-17 specifies for the Optional (O), Transitive (T) and Partial (P) bits: * for "well-known" O=3D0 T=3D1 P=3D0 * for "optional" O=3D1 T=3D0 P=3D0 or O=3D1 T=3D1 P=3DX (0 or 1) >From this, I understand:=20 =20 (a) you MUST recognise the "well-known" attributes (O=3D0); Hence: any attributes you do not recognise MUST be=20 "optional" (O=3D1);=20 (b) many "optional" (O=3D1) attributes may be very common, and=20 recognised by 99.9% of implementations, but that does not make them "well-known", within the meaning of the RFC;=20 (c) the state of T and P is independent of whether you=20 recognise the attribute or not;=20 (d) O=3D0 T=3D1 does *not* mean "required" and "transitive", it means "well-known". Whether the attribute is required inbound and/or outbound is part of its "well-known"-ness, and the attribute is said to be "mandatory"/"discretionary". T=3D1 notwithstanding, "transitive" is not a property of "well-known" attributes. [You might wonder what the sender is doing if they send an O=3D1 T=3D0 attribute which you don't recognise, but the standard requires you throw it away, anyway. Go figure.] [I agree that the Extended Length bit is independent of the Type. I have not found a requirement that the length be encoded in the minimum form for any attribute, well-known or otherwise.] The key, I think, is to realise that "well-known" has a very restricted meaning here -- it means just what RFC4271 chooses it to mean =97- neither more nor less. [Please correct me if I have misunderstood this... I regret it took me a little while to untangle what RFC4271 seemed to be saying... but it would not surprise me to learn that the RFC is vastly more subtle than I have so far been able to discern.] > > 4.2 Syntactic Correctness of NLRI Fields ... > To me it looks logical that errors in MP_REACH_NLRI which (only) > concern the Next Hop field should be treated uniformly and=20 > therefore result in treat-as-withdraw. One could actually see=20 > this as part of clause 3.d. because the Next Hop field in=20 > MP_REACH_NLRI takes the role of the well-known attribute > NEXT_HOP. >=20 > Because of that I would support Ondrej's suggestions. So the draft says "the MP_REACH_NLRI ... need to be successfully parsed", otherwise "the 'session reset' approach SHOULD be followed". (I keep banging on about this, but it does seem fundamental. Note carefully: SHOULD, not MUST... so your implementation can do something clever if it wants to ! Though there are MUSTs elsewhere which limit the wiggle room.) Now, your MP_REACH_NLRI attribute looks like this: +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Reserved (1 octet) | +---------------------------------------------------------+ | Network Layer Reachability Information (variable) | +---------------------------------------------------------+ For many AFI/SAFI the next-hop-length is expected to be one of a small number of lengths. The next-hop-length here specifies the start of the NLRI. So if the next-hop-length is not valid, it is possible that the number of octets of next hop sent is, nevertheless, correct. In this case, we might have to be deeply unlucky to find an apparently valid set of NLRI... but if we did it would be incomplete or contain rubbish. The length of the NEXT_HOP attribute, on the other hand, does not specify the start of the NLRI. This is not to say that an invalid/unexpected next-hop-length should mean that the MP_REACH_NLRI is "syntactically incorrect". But, I don't think that you can treat the Next-Hop here in exactly the same way as the NEXT-HOP attribute, just because they both specify a next-hop :-( > However, that brings me to a "bonus"-question: .... > Therefore section 7 of RFC 4760 does not apply here --even with the > above described different handling of erroneous Next Hop field in > MP_REACH_NLRI-- and MAY only be used if parsing the NLRI from > MP_{UN}REACH_NLRI could not be parsed successfully (as section 3.j. > mentions)!? The draft does say that it revises RFC4760, but unlike the other RFCs it revises, the effect on RFC4760 is less directly specified. Section 3j of the draft offers the "disabling a particular AFI/SAFI", as specified in RFC4270, as an alternative to "session-reset", if treat-as-withdraw is not possible. Were you to suggest that "disable AFI/SAFI" should be covered in Section 2 of the draft, then I would say amen. Were you to suggest that Section 6.13 could directly reference RFC4760 and summarise the effect of the draft on it, then I would say amen, again. Chris =20 From nobody Wed May 28 14:14:42 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0381A069C for ; Wed, 28 May 2014 14:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ2Bome3b2oS for ; Wed, 28 May 2014 14:14:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82EC1A068E for ; Wed, 28 May 2014 14:14:38 -0700 (PDT) Received: from CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) by CO2PR05MB729.namprd05.prod.outlook.com (10.141.228.12) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 28 May 2014 21:14:33 +0000 Received: from mnagle-sslvpn-nc.jnpr.net (66.129.241.12) by CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 28 May 2014 21:14:31 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <051401cf7aab$0d4bee30$27e3ca90$@highwayman.com> Date: Wed, 28 May 2014 17:14:34 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140514233248.GD12659@localhost> <5385EF2E.3020007@benocs.com> <051401cf7aab$0d4bee30$27e3ca90$@highwayman.com> To: Chris Hall X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR01CA012.prod.exchangelabs.com (10.141.30.42) To CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) X-Forefront-PRVS: 0225B0D5BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(377454003)(189002)(199002)(101416001)(33656002)(4396001)(47776003)(20776003)(76482001)(104166001)(77982001)(46102001)(57306001)(42186004)(85852003)(50226001)(64706001)(31966008)(74662001)(83072002)(76176999)(83716003)(79102001)(81342001)(74502001)(23746002)(89996001)(77156001)(19580395003)(50466002)(69596002)(81156002)(87976001)(53416003)(88136002)(82746002)(80022001)(83322001)(102836001)(86362001)(93916002)(99396002)(81542001)(50986999)(92726001)(92566001)(62966002)(36756003)(19580405001)(21056001)(87286001)(66066001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB731; H:mnagle-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/eiUy_sWXE4-6J_8oJ67vl0qj7YE Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:14:40 -0000 On May 28, 2014, at 3:28 PM, Chris Hall = wrote: > So the draft says "the MP_REACH_NLRI ... need to be successfully > parsed", otherwise "the 'session reset' approach SHOULD be followed". > (I keep banging on about this, but it does seem fundamental. Note > carefully: SHOULD, not MUST... so your implementation can do something > clever if it wants to ! Though there are MUSTs elsewhere which limit > the wiggle room.) You are actually reading more wiggle room than I=92d intended. The quote = with a bit more context: this entails is discussed in more detail in Section 4. If this is not possible, the procedures of [RFC4271] continue to apply, meaning that the "session reset" approach SHOULD be followed. Alternatively the error handling procedures specified in [RFC4760] for disabling a particular AFI/SAFI MAY be followed. My intention was that either you do a reset, or you disable that = AFI/SAFI per RFC4760. I think given the demonstrated ambiguity of the = formulation above, this should be changed to something like this entails is discussed in more detail in Section 4. If this is not possible, the procedures of [RFC4271] continue to apply, meaning that the "session reset" approach (or the error handling procedures specified in [RFC4760] for disabling a particular AFI/SAFI) MUST be followed. That is, unless the WG decides that something else should be done of = course.=20 =97John= From nobody Wed May 28 14:24:54 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611121A069D for ; Wed, 28 May 2014 14:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qwIYERJhLJS for ; Wed, 28 May 2014 14:24:50 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F343A1A022A for ; Wed, 28 May 2014 14:24:49 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB322.namprd05.prod.outlook.com (10.141.24.25) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 28 May 2014 21:24:45 +0000 Received: from mnagle-sslvpn-nc.jnpr.net (66.129.241.12) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 28 May 2014 21:24:42 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <051401cf7aab$0d4bee30$27e3ca90$@highwayman.com> Date: Wed, 28 May 2014 17:24:41 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140514233248.GD12659@localhost> <5385EF2E.3020007@benocs.com> <051401cf7aab$0d4bee30$27e3ca90$@highwayman.com> To: Chris Hall X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: DM2PR06CA010.namprd06.prod.outlook.com (10.141.96.40) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Forefront-PRVS: 0225B0D5BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(377454003)(199002)(189002)(52044002)(164054003)(20776003)(81542001)(81342001)(87976001)(64706001)(76482001)(81156002)(50986999)(31966008)(74662001)(83322001)(66066001)(50226001)(57306001)(83072002)(4396001)(77982001)(104166001)(46102001)(88136002)(93916002)(50466002)(76176999)(89996001)(42186004)(79102001)(36756003)(23746002)(53416003)(86362001)(21056001)(77156001)(69596002)(87286001)(92566001)(85852003)(102836001)(74502001)(19580405001)(92726001)(33656002)(62966002)(82746002)(47776003)(101416001)(80022001)(99396002)(19580395003)(83716003)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:mnagle-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/CYld4Z2fZaXx7PtDbjQJ8YsjUaY Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:24:52 -0000 On May 28, 2014, at 3:28 PM, Chris Hall = wrote: > Were you to suggest that "disable AFI/SAFI" should be covered in > Section 2 of the draft, then I would say amen. =20 Good idea. Will do. > Were you to suggest > that Section 6.13 could directly reference RFC4760 and summarise the > effect of the draft on it, then I would say amen, again. The problem with summarizing is usually that if you say the same thing = more than once you run the risk of inconsistency, which hurts in a spec. = There=92s also the problem that i don=92t have a summary in mind to put = in that section. It sounds as though you do, though =97 please feel free = to send it to the list for possible inclusion. Thanks, =97John= From nobody Wed May 28 14:34:43 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FEF1A022A for ; Wed, 28 May 2014 14:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3KxvcdXVKqz for ; Wed, 28 May 2014 14:34:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650BA1A0195 for ; Wed, 28 May 2014 14:34:40 -0700 (PDT) Received: from CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) by CO2PR05MB700.namprd05.prod.outlook.com (10.141.229.22) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 28 May 2014 21:34:34 +0000 Received: from mnagle-sslvpn-nc.jnpr.net (66.129.241.12) by CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 28 May 2014 21:34:32 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <050001cf7a82$e06e35d0$a14aa170$@highwayman.com> Date: Wed, 28 May 2014 17:34:35 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <84DDE04B-3987-4585-89A6-D1F9A8DA3209@juniper.net> References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <537B01EF.1000802@benocs.com> <5385C4D5.7030703@benocs.com> <050001cf7a82$e06e35d0$a14aa170$@highwayman.com> To: Chris Hall X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR06CA008.namprd06.prod.outlook.com (10.255.223.146) To CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) X-Forefront-PRVS: 0225B0D5BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(189002)(199002)(24454002)(82746002)(88136002)(102836001)(86362001)(80022001)(83322001)(69596002)(19580395003)(50466002)(53416003)(87976001)(81156002)(19580405001)(21056001)(87286001)(62966002)(36756003)(66066001)(99396002)(93916002)(50986999)(92726001)(92566001)(81542001)(104166001)(76482001)(46102001)(57306001)(42186004)(77982001)(33656002)(101416001)(4396001)(20776003)(47776003)(79102001)(81342001)(83716003)(23746002)(77156001)(89996001)(74502001)(64706001)(85852003)(50226001)(76176999)(83072002)(31966008)(74662001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB731; H:mnagle-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/QlcZuDR8yfdycoJjmnsULVfCxsY Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:34:41 -0000 On May 28, 2014, at 10:41 AM, Chris Hall = wrote: ... > Strictly between ourselves: I've wrestled with the requirement to > discard second and subsequent instances of the same attribute. I > confess, for the longest time I was tempted to think that > treat-as-withdraw would be the better way. But I have seen the light, > and I regret my previous heresy -- I repent and recant, and I am > saved. The scales have dropped from my eyes: it is clear to me now > that the first AS_PATH attribute in a message is blessed and anointed, > but any second or subsequent one is an abomination, and should be cast > into oblivion, and never spoken of again. I can see that now. IMO, any error for which =93attribute discard=94 is specified MAY be = handled using treat-as-withdraw instead, at the implementor=92s option. = This is basically because treat-as-withdraw is black-box identical to a = routing policy that says =93reject routes that match conditions foo=94, = and as we know (all together now!) policy is a local matter. The draft could be made to say this if the WG thinks it=92s helpful. I = haven=92t added it as yet, because it=92s not clear to me that it is. =97John= From nobody Thu May 29 07:40:35 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFA71A6F60 for ; Thu, 29 May 2014 07:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc3pJWTgY4PH for ; Thu, 29 May 2014 07:40:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CACE1A6F4A for ; Thu, 29 May 2014 07:40:08 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB230.namprd05.prod.outlook.com (10.255.191.20) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 29 May 2014 14:40:02 +0000 Received: from mnagle-sslvpn-nc.jnpr.net (66.129.241.12) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 29 May 2014 14:39:58 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: Date: Thu, 29 May 2014 10:40:01 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <5B2BC0AC-A4FA-4197-A744-671EAF4D110C@juniper.net> References: To: "Keyur Patel (keyupate)" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR03CA028.namprd03.prod.outlook.com (10.141.30.21) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Forefront-PRVS: 022649CC2C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(979002)(6009001)(428001)(51704005)(377454003)(189002)(199002)(24454002)(92566001)(69596002)(87286001)(74662001)(102836001)(85852003)(21056001)(86362001)(92726001)(77156001)(19580395003)(82746002)(47776003)(19580405001)(80022001)(83716003)(99396002)(101416001)(62966002)(83322001)(74502001)(33656002)(66066001)(31966008)(50226001)(50986999)(81342001)(4396001)(57306001)(83072002)(87976001)(64706001)(81542001)(20776003)(76482001)(81156002)(53416003)(36756003)(46102001)(23746002)(88136002)(104166001)(93916002)(77982001)(42186004)(89996001)(50466002)(76176999)(79102001)(104396001)(42262001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:mnagle-sslvpn-nc.jnpr.net; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HYUFXLluSYy-DphJGZThj4NMS-8 Cc: "draft-ietf-idr-bgp-enhanced-route-refresh@tools.ietf.org" , "idr@ietf. org" , "idr-chairs@tools.ietf.org" , "idr-ads@tools.ietf.org" Subject: Re: [Idr] AD review of draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:40:30 -0000 On May 22, 2014, at 10:58 AM, Keyur Patel (keyupate) = wrote: >> b) I see that all 8 bits of the RESERVED field are being used for = this >> purpose. Is there a reason to do so, given that only 3 values have a >> planned use? I know that there are existing implementations and I >> don't have another plan for those values - just general conservation. >> (Imagine wanting to do the same procedure but for a more limited = scope >> of routes.) >=20 > #Keyur: We have redefined the "Reserved" field to Message sub-type. 3 = bits > are used. Remaining are reserved for future use. Actually per the IANA Considerations section values 128-254 are FCFS = which is not very =93reserved=94. If we really want to accommodate this = concern, the whole registry should be Standards Action, instead of just = the bottom seven bits of it. Or I guess maybe we could make a small FCFS = range in the bottom few bits, say values 3-7, and leave the rest as SA. One hand, the registry change would be easy. Other hand, Jeff=92s point = is true too: > If we got to the point where that was truly necessary, I suspect = someone > would just allocate a new message type and make a next-generation = route > refresh. We're not exactly going through BGP message code points very > quickly. I=92m not really too bothered either way. =97John= From nobody Thu May 29 07:53:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE071A0960 for ; Thu, 29 May 2014 07:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-JG33nrFfG9 for ; Thu, 29 May 2014 07:53:17 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398AC1A6F04 for ; Thu, 29 May 2014 07:53:17 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so366316yho.1 for ; Thu, 29 May 2014 07:53:13 -0700 (PDT) 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=s6Dkdad6cLQHOaQXwbIAqU9qHebqTGtLCd11HQhr6CY=; b=va7/VG/3heGsJZ4IOZf6rHZwrHNNfb9Y4SaQIdczXg7hyww4Y2IKEe4yZSQ9+8GuAv kAU3/zZtKd/JVwNTKUiS8frhea0CvJvK26NMRCdXuI7HnleifU5jBr+PF4HBwMO091az 8iIArHvs9l25sQ3z5EUfI+aeyT4aNxCPqIL7vRaq1EiwUWzCldpDQWgfVps8pz/HccHW DNWoYvtH1lTDA7xuQJ8pJjLBtCwUQuFYHOEKNERtjMUXXpZjLwpqZRWMF3qAqOGQKSwp xUYPpd3XegAll28G+d6m3b73eNN96FrKjfcUgte/1DNJ85e/Mx/EYzQaAclOp86dXknL Wwsw== MIME-Version: 1.0 X-Received: by 10.236.81.10 with SMTP id l10mr11186971yhe.18.1401375192940; Thu, 29 May 2014 07:53:12 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Thu, 29 May 2014 07:53:12 -0700 (PDT) In-Reply-To: <5B2BC0AC-A4FA-4197-A744-671EAF4D110C@juniper.net> References: <5B2BC0AC-A4FA-4197-A744-671EAF4D110C@juniper.net> Date: Thu, 29 May 2014 10:53:12 -0400 Message-ID: From: Alia Atlas To: "John G. Scudder" Content-Type: multipart/alternative; boundary=20cf3011dca59287aa04fa8b1698 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/nK8Ew4wRtHDMqCgs6hcjsoqk5o4 Cc: "Keyur Patel \(keyupate\)" , "draft-ietf-idr-bgp-enhanced-route-refresh@tools.ietf.org" , "idr-chairs@tools.ietf.org" , "idr-ads@tools.ietf.org" , "idr@ietf. org" Subject: Re: [Idr] AD review of draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:53:18 -0000 --20cf3011dca59287aa04fa8b1698 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, Since you, Keyur and Jeff have all thought about the question and are not concerned, I see no need for any change. My concern was more conservationist and that it had been considered. Alia On Thu, May 29, 2014 at 10:40 AM, John G. Scudder wrote: > On May 22, 2014, at 10:58 AM, Keyur Patel (keyupate) > wrote: > > >> b) I see that all 8 bits of the RESERVED field are being used for this > >> purpose. Is there a reason to do so, given that only 3 values have a > >> planned use? I know that there are existing implementations and I > >> don't have another plan for those values - just general conservation. > >> (Imagine wanting to do the same procedure but for a more limited scope > >> of routes.) > > > > #Keyur: We have redefined the "Reserved" field to Message sub-type. 3 > bits > > are used. Remaining are reserved for future use. > > Actually per the IANA Considerations section values 128-254 are FCFS whic= h > is not very =E2=80=9Creserved=E2=80=9D. If we really want to accommodate = this concern, the > whole registry should be Standards Action, instead of just the bottom sev= en > bits of it. Or I guess maybe we could make a small FCFS range in the bott= om > few bits, say values 3-7, and leave the rest as SA. > > One hand, the registry change would be easy. Other hand, Jeff=E2=80=99s p= oint is > true too: > > > If we got to the point where that was truly necessary, I suspect someon= e > > would just allocate a new message type and make a next-generation route > > refresh. We're not exactly going through BGP message code points very > > quickly. > > I=E2=80=99m not really too bothered either way. > > =E2=80=94John --20cf3011dca59287aa04fa8b1698 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

Since you, Keyur and Jeff have al= l thought about the question and are not concerned,
I see no need= for any change.=C2=A0

My concern was more conserv= ationist and that it had been considered.

Alia


On Thu, May 29, 2014 at 10:40 AM, John G. Scudder <jg= s@juniper.net> wrote:
On May 22, 2014, at 10:58 AM= , Keyur Patel (keyupate) <keyupate= @cisco.com> wrote:

>> b) I see that all 8 bits of the RESERVED field are being used for = this
>> purpose. =C2=A0Is there a reason to do so, given that only 3 value= s have a
>> planned use? =C2=A0 I know that there are existing implementations= and I
>> don't have another plan for those values - just general conser= vation.
>> (Imagine wanting to do the same procedure but for a more limited s= cope
>> of routes.)
>
> #Keyur: We have redefined the "Reserved" field to Message su= b-type. 3 bits
> are used. Remaining are reserved for future use.

Actually per the IANA Considerations section values 128-254 are FCFS = which is not very =E2=80=9Creserved=E2=80=9D. If we really want to accommod= ate this concern, the whole registry should be Standards Action, instead of= just the bottom seven bits of it. Or I guess maybe we could make a small F= CFS range in the bottom few bits, say values 3-7, and leave the rest as SA.=

One hand, the registry change would be easy. Other hand, Jeff=E2=80=99s poi= nt is true too:

> If we got to the point where that was truly necessary, I suspect someo= ne
> would just allocate a new message type and make a next-generation rout= e
> refresh. =C2=A0We're not exactly going through BGP message code po= ints very
> quickly.

I=E2=80=99m not really too bothered either way.

=E2=80=94John

--20cf3011dca59287aa04fa8b1698-- From nobody Thu May 29 11:21:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A5C1A01C3 for ; Thu, 29 May 2014 11:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVz9IokENXaT for ; Thu, 29 May 2014 11:20:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D55A1A049D for ; Thu, 29 May 2014 11:20:55 -0700 (PDT) Received: from CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 29 May 2014 18:20:48 +0000 Received: from mnagle-sslvpn-nc.jnpr.net (66.129.241.12) by CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 29 May 2014 18:20:46 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <20140521155225.GD9789@pfrc> Date: Thu, 29 May 2014 14:20:50 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <25B13537-15F0-4994-8504-C04FF94C72C3@juniper.net> References: <20140521124753.GC5675@pfrc> <8540.1400685704@erosen-lnx> <20140521155225.GD9789@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR07CA021.namprd07.prod.outlook.com (10.255.223.174) To CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) X-Forefront-PRVS: 022649CC2C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(377454003)(51444003)(189002)(199002)(4396001)(81342001)(47776003)(20776003)(74502001)(79102001)(101416001)(46102001)(42186004)(77982001)(76482001)(89996001)(33656002)(83072002)(31966008)(50226001)(83716003)(85852003)(64706001)(74662001)(76176999)(23746002)(19580395003)(77156001)(50466002)(53416003)(81156002)(87976001)(88136002)(82746002)(80022001)(83322001)(102836001)(86362001)(81542001)(92726001)(15202345003)(93916002)(50986999)(57306001)(69596002)(104166001)(15975445006)(36756003)(87286001)(21056001)(99396002)(62966002)(92566001)(19580405001)(66066001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB731; H:mnagle-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/DK9ao0d8yatAX1sUxtlocC9-CNc Cc: idr@ietf.org, Eric Rosen Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:20:58 -0000 Jeff, On May 21, 2014, at 11:52 AM, Jeffrey Haas wrote: > Chairs, presuming that we do end up with that sort of behavioral = consensus > about no RT's, is an errata against RFC 4684 sufficient or would you = want to > see something more? http://www.ietf.org/iesg/statement/errata-processing.html has some = guidance for how to handle proposed errata. I think it=92s hard to argue = that this oversight in 4684 (that it=92s silent on the subject of routes = that have no RTs) is an outright error =97 it=92s an oversight. To make = matters worse, the most obvious parsing of 4684 (to me, anyway) is that = you should fail closed, not open as you propose. So the only item I see = in the guidelines that might apply is: =95 Changes that modify the working of a protocol to something = that might be different from the intended consensus when the document = was approved should be either Hold for Document Update or Rejected. = Deciding between these two depends on judgment. Changes that are clearly = modifications to the intended consensus, or involve large textual = changes, should be Rejected. In unclear situations, small changes can be = Hold for Document Update. That gives us the options of =93hold for document update=94 or = =93rejected=94. Neither one of those is what we want in order to = actually update 4684, which is =93verified=94. So I think that, = irrespective of what I want, we probably have to formally update 4684. = For that matter, I=92m not convinced that it=92s obvious that there=92s = a real WG consensus on the proposed behavior.=20 So, sorry, I do think it needs a draft of its own. =97John= From nobody Thu May 29 13:31:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614781A0666 for ; Thu, 29 May 2014 13:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPAPy1aRgGgf for ; Thu, 29 May 2014 13:30:56 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF291A0545 for ; Thu, 29 May 2014 13:30:56 -0700 (PDT) Received: from hyperion-w.halldom.com ([80.177.246.146] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Wq6yN-0001lV-VO; Thu, 29 May 2014 20:30:48 +0000 From: "Chris Hall" To: "'John G. Scudder'" References: <20140514233248.GD12659@localhost> <5385EF2E.3020007@benocs.com> <051401cf7aab$0d4bee30$27e3ca90$@highwayman.com> In-Reply-To: Date: Thu, 29 May 2014 21:30:46 +0100 Organization: Highwayman Message-ID: <059e01cf7b7c$e2502ca0$a6f085e0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMPT2U8hNZfkQob/r9whEuUIHdu9wG5qq6bASW9444BzFGB/AFP3GwfmKfUweA= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/UotMsE3yLM7Xvh6cbVgMkEab83c Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:30:58 -0000 John G. Scudder wrote (on Wed 28-May-2014 at 22:25 +0100): > On May 28, 2014, at 3:28 PM, Chris Hall wrote: .... > > Were you to suggest that Section 6.13 could directly=20 > > reference RFC4760 and summarise the effect of the draft > > on it, then I would say amen, again. > The problem with summarizing is usually that if you say the same > thing more than once you run the risk of inconsistency, which hurts > in a spec. There=92s also the problem that i don=92t have a summary in > mind to put in that section. It sounds as though you do, though =97 > please feel free to send it to the list for possible inclusion. Sure... it's no biggie, but for completeness the following references the RFC (in the same way as other subsections of section 6) and attempts to "close the loop", so that a reader of RFC4760 can see where it and the draft interact. -------------------------------------------------------- 6.13. MP_REACH_NLRI and MP_UNREACH_NLRI The handling of these attributes is discussed in Section 3 and Section 4. The error handling of [RFC4760] (Section 7) is revised as above, which, broadly speaking, replaces: "and if the speaker determines that the attribute is=20 incorrect" (in the words of RFC4760) by: "if it is not possible to 'successful parse' the attribute" (where 'successful parse' is defined above) Where an MP_REACH_NLRI or MP_UNREACH_NLRI can be successfully parsed, but is nevertheless "incorrect" then "treat-as-withdraw" MUST be used. -------------------------------------------------------- However, having written this I cannot say I find it pretty. Further, as others have observed, the handling of the Next-Hop part of the MP_REACH_NLRI attribute does not seem to be covered in the draft. Also, Section 6 covers attribute specific error handling, so why not treat MP_xx_NLRI in the same way. Thinking on... that may be done by (1) adjusting 4.2 from: Similarly, the MP_REACH_NLRI or MP_UNREACH_NLRI attribute of an update SHALL be considered to be incorrect if any of the following are true: to: Similarly, the NLRI parts of MP_REACH_NLRI and MP_UNREACH_NLRI=20 attributes SHALL be considered to be incorrect if any of the following are true: And (2) moving the last two bullets to a longer section 6.13, as follows... -------------------------------------------------------- 6.13. MP_REACH_NLRI and MP_UNREACH_NLRI The error handling of [RFC4760] (Section 7) is replaced by this specification. The error handling of [RFC4760] includes the "disable-AFI/SAFI" approach (described in Section 2,=20 above) as an option. That option is allowed in some cases in this specification, as an alternative to session-reset. These attributes SHALL be considered "syntactically incorrect" if any of the following are true: a. The attribute flags of the attribute are inconsistent with those specified in [RFC4760]. b. The length of the MP_UNREACH_NLRI attribute is less than 3, or the length of the MP_REACH_NLRI attribute is less than 5. c. The "Length of Next Hop Network Address" overruns the end of the attribute, or does not leave room for the "Reserved" byte. d. The "Network Layer Reachability Information" in an MP_REACH_NLRI attribute or the "Withdrawn Routes" in an MP_UNREACH_NLRI attribute are "syntactically incorrect" as defined in section 4.2. In all these cases "session-reset" MUST be used, except for cases (c) and (d), where "disable-AFI/SAFI" MAY be used=20 instead. An MP_REACH_NLRI attribute SHALL be considered invalid if the "Length of Next Hop Network Address" is not valid for the given AFI/SAFI, or the "Network Address of Next Hop" is not valid, and "treat-as-withdraw" MUST be used. --------------------------------------------------------=20 If the 'Length of Next Hop' is valid, but there are no NLRI then I guess that's fine. This retains the "strict" approach to the attribute flags, but is "loose" in its attitude to invalid "Length of Next Hop Network Address". Where the MP_xx_NLRI attribute is the first attribute, then being "strict" about the flags means that if there is something wrong downstream of this point, at least it isn't wrong from the get go. I'm not a big fan of taking an invalid "Length of Next Hop Network Address" at face value... but if the NLRI part of the attribute checks out (is not "syntactically incorrect"), then perhaps that is sufficient. And (3) recast 3i to be consistent with the above: i. [RFC4271] Section 6.3 specifies that: The NLRI field in the UPDATE message is checked for=20 syntactic validity. If the field is syntactically incorrect, then the Error Subcode MUST be set to Invalid Network Field. This continues to apply and is extended to the Withdrawn Routes field, so that where either field is not empty and is "syntactically incorrect" as specified in=20 Section 4.2, below, then session-reset MUST be used, but "disable-AFI/SAFI" MAY be used instead. This version of 3i and the second 6.13 above cover all the cases where broken NLRI trigger session-reset or disable-AFI/SAFI are mandated. (OK: this makes "disable-AFI/SAFI" available where previously it wasn't... but this seems symmetrical.) And, finally, (4) that leaves 3j to say: j. Finally, we observe that in order to use the approach of=20 "treat-as-withdraw", the entire NLRI field and/or the=20 MP_REACH_NLRI and MP_UNREACH_NLRI attributes need to be successfully parsed. If this is not possible, then session-reset MUST be used, but "disable-AFI/SAFI" MAY=20 be used instead, provided all AFI/SAFI in the message can be identified. Frankly, I think this brings into sharp relief the ambiguity, given the full generality of what RFC4271 and RFC4670 allow... that is, between 1 and 4 sets of NLRI. If, as previously discussed, it appears that we can de facto state that "entire" here may (safely) be *deemed* to be satisfied if any one of: o the Withdrawn Routes and/or NLRI fields are not empty. o there is a single attribute, and that is MP_UNREACH_NLRI. o an MP_REACH_NLRI has been found. then the ambiguity melts away. Sadly, because current implementations place MP_REACH_NLRI at the end of the attributes, it is vulnerable -- but there is nothing one can do about that, except to observe that it limits the benefit of the new error handling until it is widely adopted. ---------------------------------------------------------- BTW... I note this second paragraph of section 4.1 For all path attributes other than those specified as having an attribute length that may be zero it SHALL be considered a syntax error for the attribute to have a length of zero. (Of the path attributes considered in this specification, only AS_PATH and ATOMIC_AGGREGATE may validly have an attribute length of zero.) I have a feeling this is a hang-over from some previous text in which a "syntax error" had particular meaning ? I think this is superseded by Section 6, and the general requirement that all documentation for all attributes MUST specify how any and all errors are to be handled. While I'm picking nits, Section 4 is titled "Parsing of NLRI Fields", but section 4.1 is "Attribute Length Fields" in general. Chris From nobody Thu May 29 13:42:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28591A03EA for ; Thu, 29 May 2014 13:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TwmEwWac_ti for ; Thu, 29 May 2014 13:42:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B081A00EA for ; Thu, 29 May 2014 13:42:15 -0700 (PDT) Received: from CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) by CO2PR05MB556.namprd05.prod.outlook.com (10.141.196.149) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 29 May 2014 20:42:05 +0000 Received: from mnagle-sslvpn-nc.jnpr.net (66.129.241.12) by CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 29 May 2014 20:42:03 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <5385EF2E.3020007@benocs.com> Date: Thu, 29 May 2014 16:42:09 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8F39A70F-96DC-4387-A413-4FFBCCD672F3@juniper.net> References: <20140514233248.GD12659@localhost> <5385EF2E.3020007@benocs.com> To: X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR03CA028.namprd03.prod.outlook.com (10.141.30.21) To CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 022649CC2C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(164054003)(199002)(189002)(51704005)(24454002)(377454003)(33656002)(92566001)(92726001)(46102001)(21056001)(31966008)(74662001)(74502001)(104166001)(77156001)(86362001)(93916002)(36756003)(102836001)(89996001)(20776003)(47776003)(69596002)(81156002)(87976001)(76176999)(66066001)(50466002)(80022001)(50986999)(87286001)(64706001)(83716003)(88136002)(79102001)(19580395003)(82746002)(83322001)(19580405001)(50226001)(23746002)(101416001)(4396001)(77982001)(42186004)(57306001)(76482001)(81342001)(53416003)(81542001)(85852003)(83072002)(99396002)(62966002)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB731; H:mnagle-sslvpn-nc.jnpr.net; FPR:; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/dkLMiqgqKpfmqlON98UpJEDNrqY Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-08 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:42:18 -0000 On May 28, 2014, at 10:14 AM, Deniz Bahadir wrote: > Section 7 ("Error Handling") of RFC 4760 ("Multiprotocol Extension") = states that "if the speaker determines that the attribute is incorrect, = the speaker MUST delete all the BGP routes received from that neighbor = whose AFI/SAFI is the same as the one carried in the incorrect = MP_REACH_NLRI or MP_UNREACH_NLRI attribute." > When talking about "treat-as-withdraw" in the draft we are still = meaning to *only* withdraw the NLRI information enclosed in the current = UPDATE-message and not the ones received from earlier UPDATE-messages, = correct? >=20 > Therefore section 7 of RFC 4760 does not apply here --even with the = above described different handling of erroneous Next Hop field in = MP_REACH_NLRI-- and MAY only be used if parsing the NLRI from = MP_{UN}REACH_NLRI could not be parsed successfully (as section 3.j. = mentions)!? Actually I think RFC 4760 S. 7 continues in force. Paraphrasing, it says = =93if an MP_ attribute is broken, either drop all the routes or do a = session reset=94. It only talks about the MP_ attributes. draft-ietf-idr-error-handling says "MP_REACH_NLRI and MP_UNREACH_NLRI = attributes need to be successfully parsed ... If this is not possible =85 = the "session reset" approach (or the error handling procedures specified = in [RFC4760] for disabling a particular AFI/SAFI) MUST be followed.=94 These seem consistent to me.=20 Thanks, =97John= From nobody Thu May 29 14:35:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2001A0686 for ; Thu, 29 May 2014 14:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cinyoTR5T7P for ; Thu, 29 May 2014 14:35:52 -0700 (PDT) Received: from porta.halldom.com (porta.halldom.com [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208FD1A0262 for ; Thu, 29 May 2014 14:35:52 -0700 (PDT) Received: from hyperion-w.halldom.com ([80.177.246.146] helo=HYPERION) by porta.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Wq7zG-0001mR-C0 for idr@ietf.org; Thu, 29 May 2014 21:35:46 +0000 From: "Chris Hall" To: References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <537B01EF.1000802@benocs.com> <5385C4D5.7030703@benocs.com> <050001cf7a82$e06e35d0$a14aa170$@highwayman.com> <84DDE04B-3987-4585-89A6-D1F9A8DA3209@juniper.net> In-Reply-To: <84DDE04B-3987-4585-89A6-D1F9A8DA3209@juniper.net> Date: Thu, 29 May 2014 22:35:45 +0100 Organization: Highwayman Message-ID: <05a301cf7b85$f5f86fc0$e1e94f40$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHq8GuwBYAROfMVxoWKkdFU2NUYygIe4lDJAq1YM8UBryXGuQIk/bo3Ab/YPeWazhoVoA== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/idr/SflgkakbMMDj0GICJKjS8zSTRYc Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 21:35:53 -0000 John G. Scudder wrote (on Wed 28-May-2014 at 22:35 +0100)" ... > IMO, any error for which =93attribute discard=94 is specified MAY be > handled using treat-as-withdraw instead, at the implementor=92s > option. This is basically because treat-as-withdraw is black-box > identical to a routing policy that says =93reject routes that match > conditions foo=94, and as we know (all together now!) policy is a > local matter. Well... I guess... one could implement an "I think the RFC is bonkers" policy option. =20 But I think there's a deeper problem with dropping duplicate optional-transitives. The default local policy would be to follow the RFC and do this, but for optional-transitives that I don't understand, this is (effectively) inflicting my local policy on third parties. Mind you... I think the draft has a case of the conflicting MUSTs. Second and subsequent AS_PATH attributes MUST be attribute-discarded, but attribute-discard "MUST NOT be used except in the case of an attribute that has no effect on route selection or installation". Now, if the second rule wins... I am content. Since I don't know whether an unrecognised "optional transitive" has "no effect"... then I am yet more content. But this is probably wishful thinking on my part ! Chris From nobody Thu May 29 16:49:30 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E051A071B; Thu, 29 May 2014 16:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEVAwmolZzNO; Thu, 29 May 2014 16:49:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB3F1A0730; Thu, 29 May 2014 16:49:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140529234924.20688.23855.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 16:49:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/MqBmq9O6sbZ8fLKnU_Vcvi1ufD0 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 23:49:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Revised Error Handling for BGP UPDATE Messages Authors : Enke Chen John G. Scudder Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-10.txt Pages : 15 Date : 2014-05-29 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760 and 5701. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 30 05:52:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699531A0084 for ; Fri, 30 May 2014 05:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FnGJcKwGkY0 for ; Fri, 30 May 2014 05:52:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA6B1A00F9 for ; Fri, 30 May 2014 05:52:08 -0700 (PDT) Received: from CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) by CO2PR05MB585.namprd05.prod.outlook.com (10.141.197.142) with Microsoft SMTP Server (TLS) id 15.0.944.11; Fri, 30 May 2014 12:52:02 +0000 Received: from mnagle-sslvpn-nc.jnpr.net (66.129.241.12) by CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 30 May 2014 12:52:01 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <05a301cf7b85$f5f86fc0$e1e94f40$@highwayman.com> Date: Fri, 30 May 2014 08:52:06 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <537B01EF.1000802@benocs.com> <5385C4D5.7030703@benocs.com> <050001cf7a82$e06e35d0$a14aa170$@highwayman.com> <84DDE04B-3987-4585-89A6-D1F9A8DA3209@juniper.net> <05a301cf7b85$f5f86fc0$e1e94f40$@highwayman.com> To: Chris Hall X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR02CA004.namprd02.prod.outlook.com (10.255.223.152) To CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02272225C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(377454003)(51704005)(189002)(199002)(50226001)(82746002)(83322001)(19580405001)(77982001)(23746002)(83716003)(101416001)(19580395003)(79102001)(62966002)(99396002)(85852003)(83072002)(4396001)(81342001)(57306001)(76482001)(53416003)(87286001)(81542001)(42186004)(46102001)(92566001)(33656002)(31966008)(21056001)(47776003)(92726001)(76176999)(89996001)(87976001)(20776003)(80022001)(50986999)(81156002)(64706001)(66066001)(104166001)(74502001)(77156001)(74662001)(86362001)(69596002)(36756003)(50466002)(102836001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB731; H:mnagle-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AL8rIm6DYlw7x6SRsUR5uZFDBWQ Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 12:52:11 -0000 On May 29, 2014, at 5:35 PM, Chris Hall = wrote: > John G. Scudder wrote (on Wed 28-May-2014 at 22:35 +0100)" > ... >> IMO, any error for which =93attribute discard=94 is specified MAY be >> handled using treat-as-withdraw instead, at the implementor=92s >> option. This is basically because treat-as-withdraw is black-box >> identical to a routing policy that says =93reject routes that match >> conditions foo=94, and as we know (all together now!) policy is a >> local matter. >=20 > Well... I guess... one could implement an "I think the RFC is bonkers" > policy option. =20 Wouldn=92t be the first time. :-/ > But I think there's a deeper problem with dropping duplicate > optional-transitives. The default local policy would be to follow the > RFC and do this, but for optional-transitives that I don't understand, > this is (effectively) inflicting my local policy on third parties. I think Jakob has it right when he says: On May 28, 2014, at 9:57 AM, Jakob Heitz (jheitz) = wrote: > We know better than to ever invent an attribute type that can appear = more than once in an UPDATE. An UPDATE with multiple attributes of a = single type would never survive a trip through a legacy router. It is = not a serious restriction. For example, we can fit many communities into = a community attribute. This is doubly-true if we move to change the =93no duplicates=94 rule = from common practice to actually codifying it in a standard.=20 In any case, any time you configure a routing policy, you=92re = inflicting it on third parties.=20 > Mind you... I think the draft has a case of the conflicting MUSTs. > Second and subsequent AS_PATH attributes MUST be attribute-discarded, > but attribute-discard "MUST NOT be used except in the case of an > attribute that has no effect on route selection or installation". > Now, if the second rule wins... I am content. Since I don't know > whether an unrecognised "optional transitive" has "no effect"... then > I am yet more content. But this is probably wishful thinking on my > part ! Yes, I think so. I take your point that it=92s not possible to say with = absolute certainty that a second AS_PATH won=92t have an effect on route = selection and installation somewhere, so a close reading puts the two in = conflict. On the other hand, it=92s also not possible to say with = absolute certainty that the sun will rise tomorrow morning, but I still = have plans for tomorrow afternoon. The draft is in that sense a morass = of contradictions, and represents a compromise between the contributors' = sometimes individually differing sense of where the practical balance is = to be struck between rigor and laxness. The extreme pole of rigor is RFC = 4271. The extreme pole of laxness is to just quietly accept anything and = have the holdtime or a CEASE be the only things that can ever bring a = session down. We=92re trying to chart a course down the broad space = between these. Returning from philosophizing to the two MUSTs you quote, I think a good = rule of thumb to apply is that a more-specific (MUST be = attribute-discarded) takes precedence over a less-specific (MUST NOT be = used except in=85). To be honest, the latter's a guideline rather than = something that can really be considered a hard and fast rule, as our = conversation demonstrates, so I=92m going to change it in the next = version from =93MUST NOT=94 to =93must not=94.=20 Thanks a lot for all the valuable review and comments, and please keep = it coming as long as you=92ve more to say! =97John= From nobody Fri May 30 06:03:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AC31A6FFB for ; Fri, 30 May 2014 06:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvuPv4_ln4U6 for ; Fri, 30 May 2014 06:03:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685861A6FF3 for ; Fri, 30 May 2014 06:03:43 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB721.namprd05.prod.outlook.com (10.141.207.144) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 30 May 2014 13:03:37 +0000 Received: from mnagle-sslvpn-nc.jnpr.net (66.129.241.12) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 30 May 2014 13:03:36 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <20140529234924.20688.23855.idtracker@ietfa.amsl.com> Date: Fri, 30 May 2014 09:03:44 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140529234924.20688.23855.idtracker@ietfa.amsl.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR06CA007.namprd06.prod.outlook.com (10.255.223.145) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02272225C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(377424004)(69224002)(189002)(199002)(377454003)(24454002)(19580395003)(83322001)(19580405001)(4396001)(74502001)(104166001)(46102001)(33656002)(15975445006)(50466002)(69596002)(62966002)(50226001)(81342001)(74662001)(81542001)(82746002)(31966008)(101416001)(86362001)(99396002)(83072002)(77156001)(21056001)(87286001)(76176999)(89996001)(79102001)(76482001)(64706001)(81156002)(87976001)(42186004)(85852003)(57306001)(36756003)(50986999)(53416003)(92566001)(47776003)(92726001)(20776003)(66066001)(15202345003)(83716003)(23746002)(80022001)(102836001)(77982001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:mnagle-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/QhFhIcJ8WY76Bcep4dOxIaGKGjo Subject: [Idr] draft-ietf-idr-error-handling-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:03:45 -0000 As reading the rfcdiff will tell you :-) this version: - Calls out AFI/SAFI disable distinctly. - Corrects the ambiguity about attribute flags that conflict. - Removes some redundancy in 3(j). - Reworks the =93Parsing of NLRI=94 section quite a bit, including: - Extract the attribute length stuff to its own section, it didn=92t = make sense where it was. - Puts back the =93MP_ must go first=94 rule. - Adds a subsection on =93Missing NLRI=94. Thanks for all the discussion. Regards, =97John On May 29, 2014, at 7:49 PM, = wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Inter-Domain Routing Working Group of = the IETF. >=20 > Title : Revised Error Handling for BGP UPDATE = Messages > Authors : Enke Chen > John G. Scudder > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-error-handling-10.txt > Pages : 15 > Date : 2014-05-29 >=20 > Abstract: > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable as a session reset would impact not = only > routes with the offending attribute, but also other valid routes > exchanged over the session. This document partially revises the > error handling for UPDATE messages, and provides guidelines for the > authors of documents defining new attributes. Finally, it revises > the error handling procedures for a number of existing attributes. >=20 > This document updates error handling for RFCs 1997, 4271, 4360, = 4456, > 4760 and 5701. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-error-handling-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri May 30 06:05:07 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0111A700D for ; Fri, 30 May 2014 06:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty5hdVXILcVi for ; Fri, 30 May 2014 06:05:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B79111A700A for ; Fri, 30 May 2014 06:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1878; q=dns/txt; s=iport; t=1401455100; x=1402664700; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=rL2sJFvCOvuvA+nmFm9JanUtuihD0y/HE0sB+IHeGzc=; b=KRL2123XZS3ICY51qNKMzyMaWPqsui/TOCqSPfkxb5n+mvkij2O4ed5O WH6TN6oMCERhrla9If8JWnLeR0QD+hNVsoqDblGofKOzuPm7/Er36zd2P Z9249QSFo/3YA3q8ANiVp+1yl+9WJg/ocXi8HCDHOzIKlmu6TXnyiRKs8 o=; X-IronPort-AV: E=Sophos;i="4.98,941,1392163200"; d="scan'208";a="329199515" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 30 May 2014 13:04:59 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4UD4xEM013818; Fri, 30 May 2014 13:04:59 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id E82A4484; Fri, 30 May 2014 09:04:58 -0400 (EDT) From: Eric Rosen To: "John G. Scudder" In-reply-to: Your message of Thu, 29 May 2014 14:20:50 -0400. <25B13537-15F0-4994-8504-C04FF94C72C3@juniper.net> Date: Fri, 30 May 2014 09:04:58 -0400 Message-ID: <13330.1401455098@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ISfvRJdoDgMZU4t5AhZo3QHB5Ss Cc: idr@ietf.org Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 13:05:05 -0000 > For that matter, I'm not convinced that it's obvious that there's a real > WG consensus on the proposed behavior. I think everyone agrees that it should be possible to enable RTC on a particular AFI/SAFI, while allowing "RT-less routes" (routes with no RTs) of that AFI/SAFI to be distributed. I don't know whether there is consensus on the following question: should it be possible to enable RTC on a particular AFI/SAFI, while causing "RT-less" routes to be filtered? If we want to say that RT-less routes should always be distributed, no new protocol constructs are needed, just a "clarification" of the existing text. I like this approach, but perhaps it won't achieve consensus. If we want to use RTC to declare dynamically whether RT-less routes are to be distributed or whether they are to be filtered, then we need the "null-RT" construct. We would then have to decide whether (assuming RTC is enabled for a given AFI/SAFI): 1. RT-less routes get distributed unless we advertise null-RT, 2. RT-less routes get distributed only if we advertise null-RT. I like 1. myself (if we even need to have an option for filtering RT-less routes). If we need the null-RT construct, we need to specify how to code it. Now we get into a backwards compatibility issue. Perhaps it can be coded as a 96-bit NLRI, where the RT part looks like a transitive IPv4-address-specific route target with all zero in the global and local administrator fields. The hope is that this looks like a real RT to existing implementations, but won't actually match any RT. So it would be a no-op to existing implementations, and newer implementations would recognize it as a null-RT. (An alternative would be to code null-RT as, say, an eight-bit prefix of all zeroes, and to use a Capability to make sure that your peer can process it.) Comments? From nobody Fri May 30 07:29:11 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F2E1A0911 for ; Fri, 30 May 2014 07:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na4IDYIWXPj3 for ; Fri, 30 May 2014 07:29:08 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890AC1A08FB for ; Fri, 30 May 2014 07:29:08 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hl10so854738igb.9 for ; Fri, 30 May 2014 07:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=O+9XZtFK5nh7qTBLE7/gabrele+94Z26+B8ty901wpw=; b=jS5e4Y872cCcKErgoG0KgnQhXTJzTdISVPQVSRleM4tFaJs6pjdNJEQiEp/U/esJXO cWEU2WIxkr4IB1oHtDcTZQkDH6Avs9YDanCebHF+F0rQJgN6a/7XPdC2VuyHqJ3uJz6O IqjcoLf6/ayV9KkR+r0FcJzVJQLjLQ0fFea3ZBO9vy9+ha2kvCllJOducvct2E7C6ZGn 4LA8qpjYALFzDyyhwgV5GySFlmnEY9ZA1r+qAKOLcKAgYDhGQJdhEphkCW4hRz6JG19l woiRuzuXfyNw9qRK6/q4AmGM3THxNduP2Coe58QozHIMMHOPJKX8c62vGB0pSFa5n7Np Y47g== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr6124055igb.21.1401460143823; Fri, 30 May 2014 07:29:03 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 30 May 2014 07:29:03 -0700 (PDT) In-Reply-To: <13330.1401455098@erosen-lnx> References: <25B13537-15F0-4994-8504-C04FF94C72C3@juniper.net> <13330.1401455098@erosen-lnx> Date: Fri, 30 May 2014 16:29:03 +0200 X-Google-Sender-Auth: npVpzW52u02hKms1Nwo00KkrHFk Message-ID: From: Robert Raszuk To: "erosen@cisco.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/A2CxN3KOdDYbq8BMpwWTtyj-xBI Cc: idr wg Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:29:09 -0000 Hi Eric, I think the crux of your question and this topic sits really in AFI/SAFI specifics. Let's consider SAFI 128 - how good does it serve to inject to the RRs in the network say 1M of VPN routes without any RT attached to it - which perhaps by some bug or other action got into VPNv4 BGP table on any of the PEs. Take also another example of someone using RTC for SAFI 1. What good does the RTC there serves to receive all routes - including those with no RT attached when need is to only get just few procent on them. Would we need to fall back to prefix ORF there ? I am not negating that on the other side for MDT SAFI it may very well turn useful. So I would vote for defining NULL-RT while the default should be not to send any routes without intersecting RT attached or we could perhaps allow the default to be SAFI specific. As to the encoding I would see that to be complaint with current RFC4684 (96 bit field would not be) yet backwords compatible we can use all Fs in all 8 octets of the RT field. It will be backwards compatible as per RFC4360 it will never be a legal RT value (T flag is 0 for example :) Regards, R. On Fri, May 30, 2014 at 3:04 PM, Eric Rosen wrote: > >> For that matter, I'm not convinced that it's obvious that there's a real >> WG consensus on the proposed behavior. > > I think everyone agrees that it should be possible to enable RTC on a > particular AFI/SAFI, while allowing "RT-less routes" (routes with no RTs) of > that AFI/SAFI to be distributed. > > I don't know whether there is consensus on the following question: should > it be possible to enable RTC on a particular AFI/SAFI, while causing > "RT-less" routes to be filtered? > > If we want to say that RT-less routes should always be distributed, no new > protocol constructs are needed, just a "clarification" of the existing > text. I like this approach, but perhaps it won't achieve consensus. > > If we want to use RTC to declare dynamically whether RT-less routes are to > be distributed or whether they are to be filtered, then we need the > "null-RT" construct. We would then have to decide whether (assuming RTC is > enabled for a given AFI/SAFI): > > 1. RT-less routes get distributed unless we advertise null-RT, > > 2. RT-less routes get distributed only if we advertise null-RT. > > I like 1. myself (if we even need to have an option for filtering RT-less > routes). > > If we need the null-RT construct, we need to specify how to code it. Now we > get into a backwards compatibility issue. Perhaps it can be coded as a > 96-bit NLRI, where the RT part looks like a transitive IPv4-address-specific > route target with all zero in the global and local administrator fields. > The hope is that this looks like a real RT to existing implementations, but > won't actually match any RT. So it would be a no-op to existing > implementations, and newer implementations would recognize it as a null-RT. > (An alternative would be to code null-RT as, say, an eight-bit prefix of all > zeroes, and to use a Capability to make sure that your peer can process it.) > > Comments? > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri May 30 08:07:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529091A0924 for ; Fri, 30 May 2014 08:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJJHKJ5_wg5A for ; Fri, 30 May 2014 08:06:55 -0700 (PDT) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) by ietfa.amsl.com (Postfix) with ESMTP id A21011A0950 for ; Fri, 30 May 2014 08:06:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id A81CF6421A3; Fri, 30 May 2014 17:06:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKjC7R6jZLx6; Fri, 30 May 2014 17:06:46 +0200 (CEST) Received: from [192.168.1.34] (unknown [192.168.1.34]) by mail.benocs.com (Postfix) with ESMTPSA id D0EAC6420DE for ; Fri, 30 May 2014 17:06:45 +0200 (CEST) Message-ID: <53889E84.7040305@benocs.com> Date: Fri, 30 May 2014 17:06:44 +0200 From: Deniz Bahadir Organization: BENOCS GmbH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: idr@ietf.org References: <20140529234924.20688.23855.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/BmUkZ9p-acqtu8FqMsrXLJhR-Qc Subject: Re: [Idr] draft-ietf-idr-error-handling-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: deniz.bahadir@benocs.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:06:58 -0000 Hi guys, I have some more (minor) comments (or one might call it nit-picking) concerning the current draft: 1. It occurs to me that the title of section 7 ("Error Handling Procedures for Existing Attributes") implies to address *all* existing attributes. The first sentence, however, seems to mitigate that by saying the following subsections "elaborate on the conditions for error-checking *various* path attributes". Nevertheless, for sake of completeness, I would recommend to mention all (non-deprecated) path attributes (as can be found here: http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml) in the following subsections. 2. To be honest, I do not know all these path-attributes myself. However, I know AS4_PATH and AS4_AGGREGATOR, and would at least recommend to add them to the subsections of section 7. Especially, as the information given in the subsections for AS_PATH and AS_AGGREGATOR pretty much resembles the information for AS4_PATH and AS4_AGGREGATOR in section 6 of RFC 6793 (except maybe for the action taken). 3. I would also recommend to repeat (and explain) the definition of "syntactical incorrectness" for NEXT_HOP in subsection 7.3. (This seems to be the only subsection which just refers to another RFC and does not repeat the important part.) Some more nit-picking: 4. Likewise, I was always wondering, what exactly is meant by saying, "Syntactic correctness means that the NEXT_HOP attribute represents a valid IP host address." [RFC 4271, page 32]? * Does it mean, the NEXT_HOP value must be a machine that should be up and running as well as reachable (and one must explicitly check for that)? -- Probably not. * Does it mean, the NEXT_HOP must be a unicast address (neither 0.0.0.0 nor greater than 223.255.255.255)? -- Maybe. * Does it mean, the NEXT_HOP value must be a unicast address but not 127.0.0.1 or some other special IP? -- Possibly. * ... 5. Similar, I briefly looked through RFC 4760 but could not find a section telling me, if and when the value of the Next Hop field of MP_REACH_NLRI is considered (syntactically) incorrect. (At least for AFI/SAFI of IPv4/Unicast I would have expected it.) Is suppose, the current draft should address this question. (Or it shouls at least mention that MP_REACH_NLRI's Next Hop value need not be checked for (syntactical) correctness... although this does not sound right.) 6. I appreciate the ambiguity about attribute flags being addressed. Just one question: Shouldn't a well-known attribute also be considered to have conflicting flags if the partial bit is set? Thanks, Deniz Am 30.05.2014 15:03, schrieb John G. Scudder: > As reading the rfcdiff will tell you :-) this version: > > - Calls out AFI/SAFI disable distinctly. > - Corrects the ambiguity about attribute flags that conflict. > - Removes some redundancy in 3(j). > - Reworks the “Parsing of NLRI” section quite a bit, including: > - Extract the attribute length stuff to its own section, it didn’t make sense where it was. > - Puts back the “MP_ must go first” rule. > - Adds a subsection on “Missing NLRI”. > > Thanks for all the discussion. > > Regards, > > —John > > On May 29, 2014, at 7:49 PM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Inter-Domain Routing Working Group of the IETF. >> >> Title : Revised Error Handling for BGP UPDATE Messages >> Authors : Enke Chen >> John G. Scudder >> Pradosh Mohapatra >> Keyur Patel >> Filename : draft-ietf-idr-error-handling-10.txt >> Pages : 15 >> Date : 2014-05-29 >> >> Abstract: >> According to the base BGP specification, a BGP speaker that receives >> an UPDATE message containing a malformed attribute is required to >> reset the session over which the offending attribute was received. >> This behavior is undesirable as a session reset would impact not only >> routes with the offending attribute, but also other valid routes >> exchanged over the session. This document partially revises the >> error handling for UPDATE messages, and provides guidelines for the >> authors of documents defining new attributes. Finally, it revises >> the error handling procedures for a number of existing attributes. >> >> This document updates error handling for RFCs 1997, 4271, 4360, 4456, >> 4760 and 5701. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-idr-error-handling-10 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-10 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Fri May 30 08:16:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEFC1A08F1 for ; Fri, 30 May 2014 08:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrRSQ_3-QHRp for ; Fri, 30 May 2014 08:16:06 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87EC1A08EE for ; Fri, 30 May 2014 08:16:06 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id rl12so1875721iec.9 for ; Fri, 30 May 2014 08:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/ZuZfEO9148+PvQ1VtZZndq9ZpnERxBGJs7TQI01ir8=; b=ST7oxHhes/3Q+MYfw5HzEiYuyWGyCABRkIQlHdLCcfXUTdcfrbN2KyAb9tntMOTuW4 Mp86daappvJBBuIZTWFqk0PbTN90MFI35AqcJpouNJQCLKg9JG2FJ/bhedFnAPmwiVoZ Hjp56vz21evSu41bbgkyxuJmqnQYtSkV30gTEQw+MrRPLiWSYaEtllE1tGUWO3bCNClE 9qMwyTFEw+jiT0TcMR58tQJAm7w//uwLUYs74L041YKRXLinP/Lipj9ZmdTcMFEZy/CM iV4X9atCAZjstcTyj8gX+THL/obhfp+SFXuZWu/WcurD8oapr8Qacw/WcxUepVCz8ITh Ltgg== MIME-Version: 1.0 X-Received: by 10.50.43.225 with SMTP id z1mr6366130igl.29.1401462962232; Fri, 30 May 2014 08:16:02 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Fri, 30 May 2014 08:16:02 -0700 (PDT) In-Reply-To: References: <25B13537-15F0-4994-8504-C04FF94C72C3@juniper.net> <13330.1401455098@erosen-lnx> Date: Fri, 30 May 2014 17:16:02 +0200 X-Google-Sender-Auth: 2SvuPhf_XEb_Nhze5QsFF5b6uhg Message-ID: From: Robert Raszuk To: "erosen@cisco.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/O1DLAzI2RabZg9mkS__ODhE4Kcg Cc: idr wg Subject: Re: [Idr] RFC 4684 pedantry - routes with no Route Target X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:16:08 -0000 Just typo fix of the last paragraph ... s/96 bit field would not be/96 bit field would be/ So it should read: As to the encoding I would see that to be complaint with current RFC4684 (96 bit field would be) yet backwords compatible we can use all Fs in all 8 octets of the RT field. It will be backwards compatible as per RFC4360 it will never be a legal RT value (T flag is 0 for example :) Sorry, r. On Fri, May 30, 2014 at 4:29 PM, Robert Raszuk wrote: > Hi Eric, > > I think the crux of your question and this topic sits really in > AFI/SAFI specifics. > > Let's consider SAFI 128 - how good does it serve to inject to the RRs > in the network say 1M of VPN routes without any RT attached to it - > which perhaps by some bug or other action got into VPNv4 BGP table on > any of the PEs. > > Take also another example of someone using RTC for SAFI 1. What good > does the RTC there serves to receive all routes - including those with > no RT attached when need is to only get just few procent on them. > Would we need to fall back to prefix ORF there ? > > I am not negating that on the other side for MDT SAFI it may very well > turn useful. > > So I would vote for defining NULL-RT while the default should be not > to send any routes without intersecting RT attached or we could > perhaps allow the default to be SAFI specific. > > As to the encoding I would see that to be complaint with current > RFC4684 (96 bit field would not be) yet backwords compatible we can > use all Fs in all 8 octets of the RT field. It will be backwards > compatible as per RFC4360 it will never be a legal RT value (T flag is > 0 for example :) > > Regards, > R. > > > On Fri, May 30, 2014 at 3:04 PM, Eric Rosen wrote: >> >>> For that matter, I'm not convinced that it's obvious that there's a real >>> WG consensus on the proposed behavior. >> >> I think everyone agrees that it should be possible to enable RTC on a >> particular AFI/SAFI, while allowing "RT-less routes" (routes with no RTs) of >> that AFI/SAFI to be distributed. >> >> I don't know whether there is consensus on the following question: should >> it be possible to enable RTC on a particular AFI/SAFI, while causing >> "RT-less" routes to be filtered? >> >> If we want to say that RT-less routes should always be distributed, no new >> protocol constructs are needed, just a "clarification" of the existing >> text. I like this approach, but perhaps it won't achieve consensus. >> >> If we want to use RTC to declare dynamically whether RT-less routes are to >> be distributed or whether they are to be filtered, then we need the >> "null-RT" construct. We would then have to decide whether (assuming RTC is >> enabled for a given AFI/SAFI): >> >> 1. RT-less routes get distributed unless we advertise null-RT, >> >> 2. RT-less routes get distributed only if we advertise null-RT. >> >> I like 1. myself (if we even need to have an option for filtering RT-less >> routes). >> >> If we need the null-RT construct, we need to specify how to code it. Now we >> get into a backwards compatibility issue. Perhaps it can be coded as a >> 96-bit NLRI, where the RT part looks like a transitive IPv4-address-specific >> route target with all zero in the global and local administrator fields. >> The hope is that this looks like a real RT to existing implementations, but >> won't actually match any RT. So it would be a no-op to existing >> implementations, and newer implementations would recognize it as a null-RT. >> (An alternative would be to code null-RT as, say, an eight-bit prefix of all >> zeroes, and to use a Capability to make sure that your peer can process it.) >> >> Comments? >> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From nobody Fri May 30 10:45:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCDB1A6FC0 for ; Fri, 30 May 2014 10:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AauH2VWzct92 for ; Fri, 30 May 2014 10:45:28 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC681A6FB6 for ; Fri, 30 May 2014 10:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=496; q=dns/txt; s=iport; t=1401471924; x=1402681524; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j4fnJHKsmYRXzRqNzycmoTgsaDAZUNEZ7vVHD4K9G/Y=; b=IT5i8ngLqqTeJCzjW3/RbTqOElssvnAbIpCrvfydDGfOTX2H6IE2Kcyc oHMl8UtdoVGrn20GD48/9Y8J6OX4RHtj8m2Hev9QNoZKGlw+kFcKS++c5 01u9fl4TuGH/gg0Zditz7lkqm6TIduS1cMdNPhLszvay9Bg7BY9lrHW9Q A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFADHDiFOtJA2N/2dsb2JhbABZgwdSWMI8AYEJFnSCJQEBAQQ6PwwEAgEIFQEMFAkHMhQRAgQBDQUIiDoN1nIXjiExB4MrgRUBA5s8kW+DOIIv X-IronPort-AV: E=Sophos;i="4.98,942,1392163200"; d="scan'208";a="48721365" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP; 30 May 2014 17:45:23 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4UHjNlG007327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 17:45:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 30 May 2014 12:45:22 -0500 From: "Jakob Heitz (jheitz)" To: "John G. Scudder" , Chris Hall Thread-Topic: [Idr] draft-ietf-idr-error-handling-09.txt Thread-Index: AQHPemXu8TA/yWDGLUGOLwd2Eve0M5tWZL+AgABzg4CAAZKpgIABAAYA///85gA= Date: Fri, 30 May 2014 17:45:22 +0000 Message-ID: <075DE01702BBC249BE1357EFD20DCFE556F699@xmb-aln-x02.cisco.com> References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <537B01EF.1000802@benocs.com> <5385C4D5.7030703@benocs.com> <050001cf7a82$e06e35d0$a14aa170$@highwayman.com> <84DDE04B-3987-4585-89A6-D1F9A8DA3209@juniper.net> <05a301cf7b85$f5f86fc0$e1e94f40$@highwayman.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.165.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/sykZBUYg-inasx1-zljongy7ZUA Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:45:29 -0000 http://tools.ietf.org/html/rfc4271 bottom of page 24: The same attribute (attribute with the same type) cannot appear more than once within the Path Attributes field of a particular UPDATE message. --Jakob -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Friday, May 30, 2014 5:52 AM This is doubly-true if we move to change the "no duplicates" rule from comm= on practice to actually codifying it in a standard.=20 From nobody Fri May 30 10:59:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9471A036A for ; Fri, 30 May 2014 10:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hkay4Zx7k2f for ; Fri, 30 May 2014 10:59:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C211A09D3 for ; Fri, 30 May 2014 10:59:11 -0700 (PDT) Received: from BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) by BLUPR05MB006.namprd05.prod.outlook.com (10.255.210.142) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 30 May 2014 17:59:05 +0000 Received: from mnagle-sslvpn-nc.jnpr.net (66.129.241.17) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 30 May 2014 17:58:58 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: <075DE01702BBC249BE1357EFD20DCFE556F699@xmb-aln-x02.cisco.com> Date: Fri, 30 May 2014 13:59:07 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140519193351.18689.42022.idtracker@ietfa.amsl.com> <5DA14C09-9BCE-4B7C-A5BE-8F7BA3A180F2@juniper.net> <537B01EF.1000802@benocs.com> <5385C4D5.7030703@benocs.com> <050001cf7a82$e06e35d0$a14aa170$@highwayman.com> <84DDE04B-3987-4585-89A6-D1F9A8DA3209@juniper.net> <05a301cf7b85$f5f86fc0$e1e94f40$@highwayman.com> <075DE01702BBC249BE1357EFD20DCFE556F699@xmb-aln-x02.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.17] X-ClientProxiedBy: BY2PR02CA001.namprd02.prod.outlook.com (10.255.247.21) To BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02272225C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(51704005)(189002)(199002)(164054003)(377454003)(24454002)(19580395003)(19580405001)(83322001)(4396001)(93916002)(74502001)(46102001)(15975445006)(104166001)(50466002)(62966002)(50226001)(69596002)(81542001)(74662001)(81342001)(31966008)(99396002)(101416001)(86362001)(83072002)(77156001)(21056001)(88136002)(15202345003)(87286001)(76176999)(79102001)(76482001)(64706001)(81156002)(87976001)(89996001)(42186004)(47776003)(85852003)(36756003)(33656002)(53416003)(50986999)(92566001)(92726001)(57306001)(20776003)(66066001)(23746002)(102836001)(77982001)(80022001)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:mnagle-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/idr/s-jqRuVjpOHltNcz4oAPZMPZboU Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-error-handling-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:59:14 -0000 There you have it. Thanks, Jakob. =97John On May 30, 2014, at 1:45 PM, Jakob Heitz (jheitz) = wrote: > http://tools.ietf.org/html/rfc4271 bottom of page 24: >=20 > The same attribute (attribute with the same type) cannot appear more > than once within the Path Attributes field of a particular UPDATE > message. >=20 > --Jakob >=20 > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder > Sent: Friday, May 30, 2014 5:52 AM >=20 > This is doubly-true if we move to change the "no duplicates" rule from = common practice to actually codifying it in a standard.=20