From jgs@juniper.net Sun Mar 1 05:42:08 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336053A695D for ; Sun, 1 Mar 2009 05:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZjcxDgxJifr for ; Sun, 1 Mar 2009 05:42:07 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 4E2723A6842 for ; Sun, 1 Mar 2009 05:42:07 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSaqQyJY2uJsxyifwwSCHZ0XNwin6TXWo@postini.com; Sun, 01 Mar 2009 05:42:32 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 1 Mar 2009 05:40:30 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Mar 2009 05:40:30 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Mar 2009 05:40:30 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Mar 2009 05:40:30 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n21DeTM55668 for ; Sun, 1 Mar 2009 05:40:29 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> From: "John G. Scudder" To: idr List Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 1 Mar 2009 08:40:28 -0500 References: <20090301133533.BB8843A68A8@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 01 Mar 2009 13:40:30.0120 (UTC) FILETIME=[4976AA80:01C99A73] Subject: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 13:42:08 -0000 FYI. We plan to present this at the upcoming IDR meeting. URL: http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txt --John Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 1, 2009 8:35:33 AM GMT-05:00 > To: jgs@juniper.net > Cc: enkechen@cisco.com > Subject: New Version Notification for draft-scudder-idr-optional- > transitive-00 > > > A new version of I-D, draft-scudder-idr-optional-transitive-00.txt > has been successfuly submitted by John Scudder and posted to the > IETF repository. > > Filename: draft-scudder-idr-optional-transitive > Revision: 00 > Title: Error Handling for Optional Transitive BGP Attributes > Creation_date: 2009-03-01 > WG ID: Independent Submission > Number_of_pages: 6 > > 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 in the case of optional transitive > attributes. This document revises BGP's error-handling rules for > optional transitive attributes, and provides guidelines for the > authors of documents defining new optional transitive attributes. It > also revises the error handling procedures for several existing > optional transitive attributes. > > > > The IETF Secretariat. > > From narten@us.ibm.com Mon Mar 2 09:40:13 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587623A69E8 for ; Mon, 2 Mar 2009 09:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6dtpl-o05Fq for ; Mon, 2 Mar 2009 09:40:12 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id 35EE53A692A for ; Mon, 2 Mar 2009 09:40:12 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n22Hc02c026174 for ; Mon, 2 Mar 2009 10:38:00 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n22HeS85189946 for ; Mon, 2 Mar 2009 10:40:28 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n22HeReh000683 for ; Mon, 2 Mar 2009 10:40:27 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-144-115.mts.ibm.com [9.76.144.115]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n22HePs8000529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Mar 2009 10:40:27 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n22HeOpp028017; Mon, 2 Mar 2009 11:40:24 -0600 Message-Id: <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> To: Yakov Rekhter In-reply-to: <200902180028.n1I0S4M39842@magenta.juniper.net> References: <200902180028.n1I0S4M39842@magenta.juniper.net> Comments: In-reply-to Yakov Rekhter message dated "Tue, 17 Feb 2009 16:28:04 -0800." Date: Mon, 02 Mar 2009 11:40:24 -0600 From: Thomas Narten Cc: idr@ietf.org Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:40:13 -0000 Yakov Rekhter writes: > I'd like to explain a bit of the confusion surrounding the IPR > disclosure issue. On 12/23/2008 Juniper disclosed IPR on the flow-spec > draft (https://datatracker.ietf.org/ipr/1052/), but it contained > an incorrect "terms" section. Actually, I believe there is slightly more to it than this. IIRC, the December disclosure only listed a single patent application. The revised one lists one patent (issued) plus 5 patent applications (no information available AFAICT). So the disclosure has been expanded to include significantly (?) more possible IPR compared with the original disclosure. Correct? That said, the revised terms are IMO an improvement. Thanks. > The disclosure was removed at Juniper's request and resubmitted on > 02/09/2009 with the proper "terms" section. Unfortunately, Juniper's > legal team released a number of IPR disclosures on or about > 12/23/2008 and had to remove and correct all of them so, the sudden > flurry of activity may have been worrying to some. You may have seen > many corrected IPR disclosures on the IETF's IPR webpage > (https://datatracker.ietf.org/ipr/about/) and more are to > come. Juniper intended no harm or malice by these actions and > Juniper is working to make certain that disclosures are made in a > more timely manner. Regardng timing. The flow-spec document lists 6 authors, four of them with Juniper affiliations. The flow spec document was originally submitted as draft-marques-idr-flow-spec-00.txt back in June, 2003. Two of the authors on that document listed Juniper affiliations at that time. It seems surprising that the IPR that Juniper has just disclosed was only "recently" filed. If so, it is likely that there is significant prior art (since the document has been published and under discussion for so long). On the other hand, if the IPR was filed quite some time ago (i.e., when the work started), it raises the question of whether one of the IETF's most basic IPR obligations as described in RFC 3979 has been followed: 6.1.1. A Contributor's IPR in his or her Contribution Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 6.6 which the Contributor believes Covers or may ultimately Cover his or her Contribution, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6. ... 6.2.1. Timing of Disclosure Under Section 6.1.1 The IPR disclosure required pursuant to section 6.1.1 must be made as soon as reasonably possible after the Contribution is published in an Internet Draft unless the required disclosure is already on file. ... If a Contributor first learns of IPR in its Contribution that meets the conditions of Section 6.6, for example a new patent application or the discovery of a relevant patent in a patent portfolio, after the Contribution is published in an Internet-Draft, a disclosure must be made as soon as reasonably possible after the IPR becomes reasonably and personally known to the Contributor. Can the Contributers to this document please clarify the history and their role in it better w.r.t the IPR disclosures? I'm particularly concerned about the timing of the filing of the IPR and its subsequent disclosure. It seems rather odd that an ID that has been under discussion within the IETF for some 5 1/2 years would be subject of an IPR disclosure at such a late date (only after IETF LC starts) in the process. For example, do any of the patent applications list any of the document authors as inventors (and if so when was the application filed)? Or is this a case where the IETF contributers weren't involved in the patent application and wouldn't "reasonably" have been expected to known about it, i.e., as covered by the following in 3979: l. "Reasonably and personally known": means something an individual knows personally or, because of the job the individual holds, would reasonably be expected to know. This wording is used to indicate that an organization cannot purposely keep an individual in the dark about patents or patent applications just to avoid the disclosure requirement. But this requirement should not be interpreted as requiring the IETF Contributor or participant (or his or her represented organization, if any) to perform a patent search to find applicable IPR. It would be most helpful if all the contributers associated with the patent applications clarified their role to the WG, as was recently done in the case of draft-ietf-tcpm-tcp-auth-opt-03 in the TCPM WG. TCPM is also grappling with a disclosure made late in the process and the patent author in that case graciously published the patent application to help the WG in its deliberations on how to proceed. Thomas From danny@tcb.net Mon Mar 2 18:26:08 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F243A69AD for ; Mon, 2 Mar 2009 18:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.045 X-Spam-Level: * X-Spam-Status: No, score=1.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo2SmCXGcMbw for ; Mon, 2 Mar 2009 18:26:07 -0800 (PST) Received: from sa.aa.arbor.net (unknown [204.181.64.1]) by core3.amsl.com (Postfix) with ESMTP id 63AA23A69AC for ; Mon, 2 Mar 2009 18:26:07 -0800 (PST) Received: from localhost (sa.aa.arbor.net [10.1.0.64]) by sa.aa.arbor.net (Postfix) with ESMTP id 58E231700D; Mon, 2 Mar 2009 21:26:33 -0500 (EST) X-Virus-Scanned: amavisd-new at arbor.net Received: from 10-1-15-26.aa.arbor.net (10-1-15-26.aa.arbor.net [10.1.15.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sa.aa.arbor.net (Postfix) with ESMTP id 768CF16FC0; Mon, 2 Mar 2009 21:26:32 -0500 (EST) Message-Id: From: Danny McPherson To: Thomas Narten In-Reply-To: <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Mar 2009 19:26:31 -0700 References: <200902180028.n1I0S4M39842@magenta.juniper.net> <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> X-Mailer: Apple Mail (2.930.3) Cc: Yakov Rekhter , Jared Mauch , Inter-Domain Routing List Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 02:26:08 -0000 On Mar 2, 2009, at 10:40 AM, Thomas Narten wrote: > Can the Contributers to this document please clarify the history and > their role in it better w.r.t the IPR disclosures? I'm particularly > concerned about the timing of the filing of the IPR and its subsequent > disclosure. It seems rather odd that an ID that has been under > discussion within the IETF for some 5 1/2 years would be subject of an > IPR disclosure at such a late date (only after IETF LC starts) in the > process. I had no knowledge of IPR regarding flow-spec until the disclosure was filed with the IETF. Nor did Jared, I believe. -danny From danny@tcb.net Tue Mar 3 00:11:52 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D07C3A6966 for ; Tue, 3 Mar 2009 00:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.045 X-Spam-Level: * X-Spam-Status: No, score=1.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfcuXYxR4Y12 for ; Tue, 3 Mar 2009 00:11:51 -0800 (PST) Received: from sa.aa.arbor.net (unknown [204.181.64.1]) by core3.amsl.com (Postfix) with ESMTP id 29EC93A6857 for ; Tue, 3 Mar 2009 00:11:51 -0800 (PST) Received: from localhost (sa.aa.arbor.net [10.1.0.64]) by sa.aa.arbor.net (Postfix) with ESMTP id 745E317027; Tue, 3 Mar 2009 03:12:17 -0500 (EST) X-Virus-Scanned: amavisd-new at arbor.net Received: from 10-1-15-26.aa.arbor.net (10-1-15-26.aa.arbor.net [10.1.15.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sa.aa.arbor.net (Postfix) with ESMTP id 4652D16FC0; Tue, 3 Mar 2009 03:12:16 -0500 (EST) Message-Id: <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> From: Danny McPherson To: John G. Scudder In-Reply-To: <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 01:12:14 -0700 References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> X-Mailer: Apple Mail (2.930.3) Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 08:11:52 -0000 On Mar 1, 2009, at 6:40 AM, John G. Scudder wrote: > FYI. We plan to present this at the upcoming IDR meeting. > > URL: http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txt Some comments on the draft... - I'm not sure I like the recommended behavior in S 2 where we're treating malformed updates "as though all contained prefixes had been withdrawn". I'd strongly prefer that in ALL cases the update be discarded. Making assumptions and providing rules for how to selectively handle mal-formed updates seems much like something you yourself would caution us against. I'd much prefer a 'discard and log' requirement. - I could see how this text is S 2. might not be the case, if varying implementations handle a given update in different ways: "This is likewise the case if an optional transitive attribute is received whose Partial bit is not set -- this is because the detected error can be imputed to the direct peer." No other comments, I think this is a useful document. -danny From robert@raszuk.net Tue Mar 3 01:36:55 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E9928C1F7 for ; Tue, 3 Mar 2009 01:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F99DlPtla7ll for ; Tue, 3 Mar 2009 01:36:54 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 7075828C178 for ; Tue, 3 Mar 2009 01:36:54 -0800 (PST) Received: (qmail 19435 invoked by uid 399); 3 Mar 2009 09:37:20 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.4.248) by mail37.opentransfer.com with SMTP; 3 Mar 2009 09:37:20 -0000 Message-ID: <49ACFA4C.4060609@raszuk.net> Date: Tue, 03 Mar 2009 01:37:16 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Thomas Narten References: <200902180028.n1I0S4M39842@magenta.juniper.net> <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> In-Reply-To: <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 09:36:55 -0000 Hi Thomas, Since the original draft's publication date June 2003 (well even earlier as I started to discuss this idea with Pedro Marques around beg of 2003 if not earlier) I was fully aware about Juniper's authors filing the patent application for this work. There was no mystery of any sort made reg this filing. That was and still is the common industry practice in any vendor for any novel work which is going to be publicly presented. AFAIK you can safely assume that vast majority of IETF drafts have patents filed behind. The fact that some lawyers did not disclosed it on time is regrettable, but should not be a point of any discussion in IDR WG. As I recommended already before if such disclosures are so important IETF should add a mandatory section of any draft template or mandatory field on the draft submission page to list them or explicitly state "none". Having the draft publishing and IPR disclosures submission taking totally independent paths as it is today is just a clear receipt for more cases like this one to happen. Header of the original authors/co-authors: Network Working Group Pedro Marques INTERNET DRAFT Nischal Sheth Expiration Date: December 2003 Juniper Networks, Inc Robert Raszuk Cisco Systems, Inc Jared Mauch NTT/Verio Danny McPherson Arbor Networks June 2003 Cheers, R. > Yakov Rekhter writes: > >> I'd like to explain a bit of the confusion surrounding the IPR >> disclosure issue. On 12/23/2008 Juniper disclosed IPR on the flow-spec >> draft (https://datatracker.ietf.org/ipr/1052/), but it contained >> an incorrect "terms" section. > > Actually, I believe there is slightly more to it than this. IIRC, the > December disclosure only listed a single patent application. The > revised one lists one patent (issued) plus 5 patent applications (no > information available AFAICT). So the disclosure has been expanded to > include significantly (?) more possible IPR compared with the original > disclosure. > > Correct? > > That said, the revised terms are IMO an improvement. Thanks. > >> The disclosure was removed at Juniper's request and resubmitted on >> 02/09/2009 with the proper "terms" section. Unfortunately, Juniper's >> legal team released a number of IPR disclosures on or about >> 12/23/2008 and had to remove and correct all of them so, the sudden >> flurry of activity may have been worrying to some. You may have seen >> many corrected IPR disclosures on the IETF's IPR webpage >> (https://datatracker.ietf.org/ipr/about/) and more are to >> come. Juniper intended no harm or malice by these actions and >> Juniper is working to make certain that disclosures are made in a >> more timely manner. > > Regardng timing. The flow-spec document lists 6 authors, four of them > with Juniper affiliations. > > The flow spec document was originally submitted as > draft-marques-idr-flow-spec-00.txt back in June, 2003. Two of the > authors on that document listed Juniper affiliations at that time. > > It seems surprising that the IPR that Juniper has just disclosed was > only "recently" filed. If so, it is likely that there is significant > prior art (since the document has been published and under discussion > for so long). On the other hand, if the IPR was filed quite some time > ago (i.e., when the work started), it raises the question of whether > one of the IETF's most basic IPR obligations as described in RFC 3979 > has been followed: > > 6.1.1. A Contributor's IPR in his or her Contribution > > Any Contributor who reasonably and personally knows of IPR meeting > the conditions of Section 6.6 which the Contributor believes Covers > or may ultimately Cover his or her Contribution, or which the > Contributor reasonably and personally knows his or her employer or > sponsor may assert against Implementing Technologies based on such > Contribution, must make a disclosure in accordance with this Section > 6. > > ... > > 6.2.1. Timing of Disclosure Under Section 6.1.1 > > The IPR disclosure required pursuant to section 6.1.1 must be made as > soon as reasonably possible after the Contribution is published in an > Internet Draft unless the required disclosure is already on file. > > ... > > If a Contributor first learns of IPR in its Contribution that meets > the conditions of Section 6.6, for example a new patent application > or the discovery of a relevant patent in a patent portfolio, after > the Contribution is published in an Internet-Draft, a disclosure must > be made as soon as reasonably possible after the IPR becomes > reasonably and personally known to the Contributor. > > Can the Contributers to this document please clarify the history and > their role in it better w.r.t the IPR disclosures? I'm particularly > concerned about the timing of the filing of the IPR and its subsequent > disclosure. It seems rather odd that an ID that has been under > discussion within the IETF for some 5 1/2 years would be subject of an > IPR disclosure at such a late date (only after IETF LC starts) in the > process. > > For example, do any of the patent applications list any of the > document authors as inventors (and if so when was the application > filed)? Or is this a case where the IETF contributers weren't involved > in the patent application and wouldn't "reasonably" have been expected > to known about it, i.e., as covered by the following in 3979: > > l. "Reasonably and personally known": means something an individual > knows personally or, because of the job the individual holds, > would reasonably be expected to know. This wording is used to > indicate that an organization cannot purposely keep an individual > in the dark about patents or patent applications just to avoid the > disclosure requirement. But this requirement should not be > interpreted as requiring the IETF Contributor or participant (or > his or her represented organization, if any) to perform a patent > search to find applicable IPR. > > It would be most helpful if all the contributers associated with the > patent applications clarified their role to the WG, as was recently > done in the case of draft-ietf-tcpm-tcp-auth-opt-03 in the TCPM > WG. TCPM is also grappling with a disclosure made late in the process > and the patent author in that case graciously published the patent > application to help the WG in its deliberations on how to proceed. > > Thomas > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From robert@raszuk.net Tue Mar 3 02:11:07 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CAF3A6A15 for ; Tue, 3 Mar 2009 02:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXyPw4Bfr5ab for ; Tue, 3 Mar 2009 02:11:06 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id F384528C21D for ; Tue, 3 Mar 2009 02:11:02 -0800 (PST) Received: (qmail 13536 invoked by uid 399); 3 Mar 2009 10:11:29 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.4.248) by mail37.opentransfer.com with SMTP; 3 Mar 2009 10:11:29 -0000 Message-ID: <49AD024D.5030902@raszuk.net> Date: Tue, 03 Mar 2009 02:11:25 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Danny McPherson References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> In-Reply-To: <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 10:11:07 -0000 Hi Danny, > contained prefixes had been withdrawn". I'd strongly > prefer that in ALL cases the update be discarded. Wouldn't making "silent" update discard lead to stale BGP paths sitting in the network as long as the session they were received on is up ? I am thinking about implicit/explicit withdraws in fact in both ebgp and ibgp cases. Do we making in this draft an implicit assumption that transitive attribute malformation must always happen day one and not after the original advertisement have already left the originator ? I think the current text at least suggest that if withdraw of NLRIs is possible when we drop the update let's dispatch it. I personally don't like the "if" part. If we make a protocol decision optimized for "most common" scenarios and not "all cases" IMHO we are already starting to cut the branch we are sitting on. "While lamentable, this issue is expected to be rare in practice, and more importantly is seen as less problematic than the session-reset behavior it replaces." I would actually propose to drop the update _only_ if withdraw of NLRIs it contains can be generated. If not continue today's behavior to drop the session. Having even if "rear in practice" black wholes is quite scary if some folks are already looking at using IP to control for example commercial aircrafts. Two additional points to the claim that dropping the session is worst thing ... * We design a mechanism without any assumption if 1% or 99% or received updates contain a malformed transitive optional attribute. If it is the latter wouldn't dropping the session be actually much cleaner solution network wide ? * Considering bigger picture and the consequence of dropping the session it is true that today it may result in BGP churn and potential for traffic disruption. But let's keep in mind that more and more tools are being introduced across vendors to allow you to have path redundancy already in place for each net. That combined with peering redundancy would effectively result in a very localized path switchovers with almost negligible network wide consequences of single session drop. Cheers, R. > On Mar 1, 2009, at 6:40 AM, John G. Scudder wrote: > >> FYI. We plan to present this at the upcoming IDR meeting. >> >> URL: >> http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txt >> > > Some comments on the draft... > > - > I'm not sure I like the recommended behavior in S 2 > where we're treating malformed updates "as though all > contained prefixes had been withdrawn". I'd strongly > prefer that in ALL cases the update be discarded. > Making assumptions and providing rules for how to > selectively handle mal-formed updates seems much like > something you yourself would caution us against. I'd > much prefer a 'discard and log' requirement. > > - > I could see how this text is S 2. might not be the case, > if varying implementations handle a given update in > different ways: > > "This is likewise the case if an optional transitive > attribute is received whose Partial bit is not set -- > this is because the detected error can be imputed to > the direct peer." > > > No other comments, I think this is a useful document. > > -danny > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From jgs@juniper.net Tue Mar 3 05:41:14 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805F83A6C5E for ; Tue, 3 Mar 2009 05:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYvh5akpVCq0 for ; Tue, 3 Mar 2009 05:41:13 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 745DB3A6C5C for ; Tue, 3 Mar 2009 05:41:13 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSa0zlHA+e11MN+3lubSwVjoMhlnXwS+z@postini.com; Tue, 03 Mar 2009 05:41:40 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 3 Mar 2009 05:40:49 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 05:40:49 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 05:40:49 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 05:40:48 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n23DekM39418; Tue, 3 Mar 2009 05:40:46 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: From: "John G. Scudder" To: Danny McPherson In-Reply-To: <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 08:40:45 -0500 References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Mar 2009 13:40:48.0464 (UTC) FILETIME=[A9393D00:01C99C05] Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 13:41:14 -0000 On Mar 3, 2009, at 3:12 AM, Danny McPherson wrote: > I'm not sure I like the recommended behavior in S 2 > where we're treating malformed updates "as though all > contained prefixes had been withdrawn". I'd strongly > prefer that in ALL cases the update be discarded. > Making assumptions and providing rules for how to > selectively handle mal-formed updates seems much like > something you yourself would caution us against. I'd > much prefer a 'discard and log' requirement. The example below should refresh your memory of why "discard" doesn't fly. "Treat as withdraw" is basically the closest *safe* version of "discard". --John > From: "John G. Scudder" > Date: December 15, 2008 2:34:34 PM GMT-05:00 > To: Danny McPherson > Cc: Jeffrey Haas , cayle.spandon@gmail.com, Enke > Chen , quaizar.vohra@gmail.com, skh@nexthop.com, > Inter-Domain Routing List , Yakov Rekhter >, Tony Li , Quaizar Vohra > Subject: Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes > > On Dec 15, 2008, at 2:21 PM, Danny McPherson wrote: >> After thinking about this for a few minutes, I can't currently >> come up with any configuration where a forwarding loop would occur >> as a result of just dropping the update (because the "translation" >> occurs on ingress to an AS), so discarding the update is likely >> to be a cleaner action. > > > AS1---AS2 > \ / > \ / > AS3 > > - AS1 prefers to reach AS3 directly, and advertises its route to AS2. > - AS2 prefers to reach AS3 directly, and advertises its route to AS1. > - Connections AS3-AS1 and AS3-AS2 fail simultaneously. > - AS1 switches to prefer AS2's route, and sends an update message > which > includes a withdraw of its previous announcement. The withdraw is > bundled with some advertisements. It includes a bad attribute. > As a > result, AS2 ignores the message. > - AS2 switches to prefer AS1's route, and sends an update message > which > includes a withdraw of its previous announcement. The withdraw is > bundled with some advertisements. It includes a bad attribute. > As a > result, AS1 ignores the message. > > End result is that AS1 forwards traffic for AS3 towards AS2, and AS2 > forwards traffic for AS3 towards AS1. This is a permanent (until > corrected) forwarding loop. > > I'm sure a less-contrived example can also be constructed, but this > one should be sufficient to prove the point. > > --John From jgs@juniper.net Tue Mar 3 05:52:01 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514233A6A07 for ; Tue, 3 Mar 2009 05:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDUSrLjNc8DF for ; Tue, 3 Mar 2009 05:52:00 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 30A7B3A688A for ; Tue, 3 Mar 2009 05:52:00 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSa02G00YRNR9l2QtXNb2kJkr7gG4e1cj@postini.com; Tue, 03 Mar 2009 05:52:27 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 3 Mar 2009 05:50:50 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 05:50:50 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 05:50:49 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 05:50:49 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n23DomM44642; Tue, 3 Mar 2009 05:50:48 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: <55830A88-66A0-453B-84B3-4E9FEEC8DB26@juniper.net> From: "John G. Scudder" To: Danny McPherson In-Reply-To: <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 08:50:47 -0500 References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Mar 2009 13:50:49.0121 (UTC) FILETIME=[0F3E3910:01C99C07] Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 13:52:01 -0000 On Mar 3, 2009, at 3:12 AM, Danny McPherson wrote: > I could see how this text is S 2. might not be the case, > if varying implementations handle a given update in > different ways: > > "This is likewise the case if an optional transitive > attribute is received whose Partial bit is not set -- > this is because the detected error can be imputed to > the direct peer." Can you be more specific about this? It seems to me that the behavior for setting the Partial bit is fully specified, so all compliant & correct implementations should behave more or less the same in that respect. Since the relevant corollary in this case is that if the Partial bit is not set we know that the direct peer recognized the path attribute (else it would have set the Partial bit), I guess we can focus on what the consequences are if that is NOT done. Case 1 is when the direct peer doesn't set Partial even though it doesn't recognize the attribute. In that case we would falsely "blame" the direct peer for the detected malformation and reset the session. I think this is OK insofar as the direct peer *does* have a bug in its path attribute handling in this scenario, although not the one we think it does. Case 2 is when the direct peer recognizes the attribute but sets Partial anyway. In that case we would mistakenly give the direct peer a free pass instead of "blaming" it, and would follow the treat-as- withdraw behavior instead of resetting the session. This isn't ideal, but we already think treat-as-withdraw is OK as the general-case error- handling behavior -- session reset is an optimization. So I think that's OK. (Also I think these scenarios are pretty far-fetched.) Based on this I'm comfortable with relying on the Partial bit. If we weren't going to do this the question would be, what to do instead? --John From jgs@juniper.net Tue Mar 3 06:01:33 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8B328C100 for ; Tue, 3 Mar 2009 06:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g7IuOt-ZV8K for ; Tue, 3 Mar 2009 06:01:33 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 2DC5328C104 for ; Tue, 3 Mar 2009 06:01:33 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSa04VfEF/4IUblCVRcd7n4slHIvpGGsT@postini.com; Tue, 03 Mar 2009 06:02:00 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 3 Mar 2009 06:00:18 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 06:00:18 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 06:00:18 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 06:00:17 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n23E0FM49677; Tue, 3 Mar 2009 06:00:16 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: From: "John G. Scudder" To: robert@raszuk.net In-Reply-To: <49AD024D.5030902@raszuk.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 09:00:15 -0500 References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> <49AD024D.5030902@raszuk.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Mar 2009 14:00:17.0497 (UTC) FILETIME=[62058490:01C99C08] Cc: idr List , Danny McPherson Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 14:01:34 -0000 Hi Robert, On Mar 3, 2009, at 5:11 AM, Robert Raszuk wrote: > Do we making in this draft an implicit assumption that transitive > attribute malformation must always happen day one and not after the > original advertisement have already left the originator ? No, the draft applies equally regardless of where the malformation is introduced. > I think the current text at least suggest that if withdraw of NLRIs > is possible when we drop the update let's dispatch it. Sorry, didn't follow the above. > Two additional points to the claim that dropping the session is > worst thing ... I'd be interested in feedback from the WG regarding the question of withdrawing the routes (what the draft proposes) vs. dropping the session (current behavior). Especially feedback from network operators. --John From jhaas@slice.pfrc.org Tue Mar 3 06:54:30 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7523A6A55 for ; Tue, 3 Mar 2009 06:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2u7IB9PuIHl for ; Tue, 3 Mar 2009 06:54:29 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id A2F403A6929 for ; Tue, 3 Mar 2009 06:54:29 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 68916244181; Tue, 3 Mar 2009 14:54:56 +0000 (UTC) Date: Tue, 3 Mar 2009 09:54:56 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20090303145454.GB7778@slice> References: <200902231534.n1NFYSM53254@magenta.juniper.net> <014b01c99672$7438fde0$0601a8c0@allison> <20090224155747.GA23230@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090224155747.GA23230@slice> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Subject: [Idr] Withdrawing request for early assignment of mib-2 OIDs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 14:54:30 -0000 After further discussion with our MIB doctor and the working group chairs, I'd like to withdraw my request for an early allocation for mib-2 OIDs for the BGP MIBv2 MIBs. We would like to get the MIBs a little further along in the standardization process before we take that step. -- Jeff From robert@raszuk.net Tue Mar 3 07:22:06 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A7C3A6835 for ; Tue, 3 Mar 2009 07:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8O95lltvNG3 for ; Tue, 3 Mar 2009 07:22:06 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id C96B33A682A for ; Tue, 3 Mar 2009 07:22:05 -0800 (PST) Received: (qmail 32726 invoked by uid 399); 3 Mar 2009 15:22:32 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.218.43) by mail37.opentransfer.com with SMTP; 3 Mar 2009 15:22:32 -0000 Message-ID: <49AD4B34.6050209@raszuk.net> Date: Tue, 03 Mar 2009 07:22:28 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "John G. Scudder" References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> <49AD024D.5030902@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr List , Danny McPherson Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 15:22:06 -0000 Hi John, Let me clarify ... Note that this option requires that the NLRI field and/or MP_REACH [RFC4760] attribute be successfully parsed. In the case of an optional transitive attribute which has no effect on route selection or installation, the malformed attribute MAY instead be discarded. An example of such an attribute is the AGGREGATOR attribute. In any case, an error in an optional transitive attribute whose Partial bit is set MUST NOT be responded to by sending a NOTIFICATION message or resetting the BGP session. The draft in the current form says to withdraw the routes if malformed partial transitive optional attribute which has an effect on routing is received within the BGP update msg. That is fine. (My email was actually in support on this behavior in response to Danny's mail). On the other hand the draft is confusing in defining the behavior on when such NLRI can not be parsed. That would effectively mean that the update itself can not be parsed and is silently dropped. I am just questioning that part of this draft. The draft says: "In any case, an error in an optional transitive attribute whose Partial bit is set MUST NOT be responded to by sending a NOTIFICATION message or resetting the BGP session." So if an optional transitive attribute whose Partial bit is set has an error in it's length field we can not reset the session. That is IMHO too strong of requirement. > I'd be interested in feedback from the WG regarding the question of > withdrawing the routes (what the draft proposes) vs. dropping the > session (current behavior). Especially feedback from network > operators. Exactly. In particular I would like to get other's opinion of the previously stated questions ... * What is better to drop the session or to drop 99% of updates with such session ? * What people who design mission critical applications based on BGP feel about protocol not being robust in all cases and allowing for "rare in practice" black wholes ? In other words today we pretty well know how to build redundant and robust networks for such applications by introducing additional peering sessions, dual vendor networks etc .. But that works as long as protocol is 100% accurate. If you would start optimizing it for most common cases that will likely result in introduction of whole new dimension to network design best practices. More over such silent update drop dimension may be very difficult to architect around. Cheers, R. > Hi Robert, > > On Mar 3, 2009, at 5:11 AM, Robert Raszuk wrote: >> Do we making in this draft an implicit assumption that transitive >> attribute malformation must always happen day one and not after the >> original advertisement have already left the originator ? > > No, the draft applies equally regardless of where the malformation is > introduced. > >> I think the current text at least suggest that if withdraw of NLRIs is >> possible when we drop the update let's dispatch it. > > Sorry, didn't follow the above. > >> Two additional points to the claim that dropping the session is worst >> thing ... > > I'd be interested in feedback from the WG regarding the question of > withdrawing the routes (what the draft proposes) vs. dropping the > session (current behavior). Especially feedback from network operators. > > --John > > From jgs@juniper.net Tue Mar 3 08:52:02 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B93D3A69D1 for ; Tue, 3 Mar 2009 08:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuWQPgQ09S1b for ; Tue, 3 Mar 2009 08:51:59 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 250C73A6911 for ; Tue, 3 Mar 2009 08:51:59 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSa1gSJoiawCzADqu08/wvOMzLuZQcJHx@postini.com; Tue, 03 Mar 2009 08:52:26 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 3 Mar 2009 08:50:52 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 08:50:51 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 08:50:51 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 08:50:51 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n23GonM32472; Tue, 3 Mar 2009 08:50:49 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: <5C5A67FB-FA71-44D9-8772-EE46F543A571@juniper.net> From: "John G. Scudder" To: robert@raszuk.net In-Reply-To: <49AD4B34.6050209@raszuk.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 11:50:48 -0500 References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> <49AD024D.5030902@raszuk.net> <49AD4B34.6050209@raszuk.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Mar 2009 16:50:51.0208 (UTC) FILETIME=[35C9E480:01C99C20] Cc: idr List , Danny McPherson Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 16:52:02 -0000 Thanks for clarifying, Robert. On Mar 3, 2009, at 10:22 AM, Robert Raszuk wrote: > Let me clarify ... > > Note > that this option requires that the NLRI field and/or MP_REACH > [RFC4760] attribute be successfully parsed. In the case of an > optional transitive attribute which has no effect on route selection > or installation, the malformed attribute MAY instead be discarded. > An example of such an attribute is the AGGREGATOR attribute. In any > case, an error in an optional transitive attribute whose Partial bit > is set MUST NOT be responded to by sending a NOTIFICATION message or > resetting the BGP session. > > The draft in the current form says to withdraw the routes if > malformed partial transitive optional attribute which has an effect > on routing is received within the BGP update msg. That is fine. (My > email was actually in support on this behavior in response to > Danny's mail). > > On the other hand the draft is confusing in defining the behavior on > when such NLRI can not be parsed. That would effectively mean that > the update itself can not be parsed and is silently dropped. I am > just questioning that part of this draft. Ah! That was not the intent. That sentence ("Note that this option requires that the NLRI field and/or MP_REACH [RFC4760] attribute be successfully parsed") is non-normative and is meant to draw the attention of implementors to exactly the problem you're pointing out. Two paragraphs down the draft says that if the UPDATE is broken in any other way the normal reset behavior is followed. ("In the event that an UPDATE message is deemed to be malformed in any other way... the procedures of [RFC4271] continue to apply.") I'll take a note to clarify this in -01, either by removing the sentence which caused the confusion, explicitly calling out non- parseable NLRI as an example of a fatal error, or both. > The draft says: "In any case, an error in an optional transitive > attribute whose Partial bit is set MUST NOT be responded to by > sending a NOTIFICATION message or resetting the BGP session." > > So if an optional transitive attribute whose Partial bit is set has > an error in it's length field we can not reset the session. That is > IMHO too strong of requirement. Not sure why you see this as a problem -- as long as the error is restricted to that particular optional transitive attribute, that is exactly the error case this draft is trying to cover. Indeed for practical purposes length field errors are the majority of discoverable errors in optional transitives. And the same exact problems apply for length field as any other error -- that is, routers which do not recognize that particular attribute are unable to validate the length field since they don't know what the length is supposed to be. I do agree (see above) that if there is any error in the UPDATE other than one restricted to an optional transitive Partial attribute, RFC 4271 rules should continue to apply. > More over such silent update drop dimension may be very difficult to > architect around. To reiterate, "silent update drop" isn't the intent of the draft and we'll strive to make this even clearer in the next version. Thanks, --John From robert@raszuk.net Tue Mar 3 09:44:18 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6973A67B5 for ; Tue, 3 Mar 2009 09:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkS7t4sg7ZmL for ; Tue, 3 Mar 2009 09:44:17 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 14D1A3A6774 for ; Tue, 3 Mar 2009 09:44:16 -0800 (PST) Received: (qmail 5374 invoked by uid 399); 3 Mar 2009 17:44:43 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.4.248) by mail37.opentransfer.com with SMTP; 3 Mar 2009 17:44:43 -0000 Message-ID: <49AD6C89.1050604@raszuk.net> Date: Tue, 03 Mar 2009 09:44:41 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "John G. Scudder" References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> <49AD024D.5030902@raszuk.net> <49AD4B34.6050209@raszuk.net> <5C5A67FB-FA71-44D9-8772-EE46F543A571@juniper.net> In-Reply-To: <5C5A67FB-FA71-44D9-8772-EE46F543A571@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr List , Danny McPherson Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:44:18 -0000 Hi John, It's so great to be in sync ! > To reiterate, "silent update drop" isn't the intent of the draft and > we'll strive to make this even clearer in the next version. I would just propose a one sentence to be added to make it cristal clear ... "If due to an errors, including those propagated in transitive attributes, the other attributes of the update message can not be correctly parsed the entire update is considered invalid and procedures of [RFC4271] continue to apply. that would clearly contradict with the text below which perhaps needs to be re-edited a bit too. >> The draft says: "In any case, an error in an optional transitive >> attribute whose Partial bit is set MUST NOT be responded to by >> sending a NOTIFICATION message or resetting the BGP session." Cheers & Thx R. > Thanks for clarifying, Robert. > > On Mar 3, 2009, at 10:22 AM, Robert Raszuk wrote: >> Let me clarify ... >> >> Note >> that this option requires that the NLRI field and/or MP_REACH >> [RFC4760] attribute be successfully parsed. In the case of an >> optional transitive attribute which has no effect on route selection >> or installation, the malformed attribute MAY instead be discarded. >> An example of such an attribute is the AGGREGATOR attribute. In any >> case, an error in an optional transitive attribute whose Partial bit >> is set MUST NOT be responded to by sending a NOTIFICATION message or >> resetting the BGP session. >> >> The draft in the current form says to withdraw the routes if malformed >> partial transitive optional attribute which has an effect on routing >> is received within the BGP update msg. That is fine. (My email was >> actually in support on this behavior in response to Danny's mail). >> >> On the other hand the draft is confusing in defining the behavior on >> when such NLRI can not be parsed. That would effectively mean that the >> update itself can not be parsed and is silently dropped. I am just >> questioning that part of this draft. > > Ah! That was not the intent. That sentence ("Note that this option > requires that the NLRI field and/or MP_REACH [RFC4760] attribute be > successfully parsed") is non-normative and is meant to draw the > attention of implementors to exactly the problem you're pointing out. > Two paragraphs down the draft says that if the UPDATE is broken in any > other way the normal reset behavior is followed. ("In the event that an > UPDATE message is deemed to be malformed in any other way... the > procedures of [RFC4271] continue to apply.") > > I'll take a note to clarify this in -01, either by removing the sentence > which caused the confusion, explicitly calling out non-parseable NLRI as > an example of a fatal error, or both. > >> The draft says: "In any case, an error in an optional transitive >> attribute whose Partial bit is set MUST NOT be responded to by sending >> a NOTIFICATION message or resetting the BGP session." >> >> So if an optional transitive attribute whose Partial bit is set has an >> error in it's length field we can not reset the session. That is IMHO >> too strong of requirement. > > Not sure why you see this as a problem -- as long as the error is > restricted to that particular optional transitive attribute, that is > exactly the error case this draft is trying to cover. Indeed for > practical purposes length field errors are the majority of discoverable > errors in optional transitives. And the same exact problems apply for > length field as any other error -- that is, routers which do not > recognize that particular attribute are unable to validate the length > field since they don't know what the length is supposed to be. I do > agree (see above) that if there is any error in the UPDATE other than > one restricted to an optional transitive Partial attribute, RFC 4271 > rules should continue to apply. > >> More over such silent update drop dimension may be very difficult to >> architect around. > > To reiterate, "silent update drop" isn't the intent of the draft and > we'll strive to make this even clearer in the next version. > > Thanks, > > --John > > From jgs@juniper.net Tue Mar 3 09:52:07 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11D983A6A07 for ; Tue, 3 Mar 2009 09:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxR7UPSQiq9B for ; Tue, 3 Mar 2009 09:52:06 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 367CD3A69BB for ; Tue, 3 Mar 2009 09:52:06 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSa1uXvgGzP/2OkhSdTKA9a8rig/ECJZy@postini.com; Tue, 03 Mar 2009 09:52:33 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 3 Mar 2009 09:51:41 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 09:51:41 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 09:51:40 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 09:51:40 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n23HpdM62835; Tue, 3 Mar 2009 09:51:39 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: From: "John G. Scudder" To: robert@raszuk.net In-Reply-To: <49AD6C89.1050604@raszuk.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 12:51:38 -0500 References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> <49AD024D.5030902@raszuk.net> <49AD4B34.6050209@raszuk.net> <5C5A67FB-FA71-44D9-8772-EE46F543A571@juniper.net> <49AD6C89.1050604@raszuk.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Mar 2009 17:51:40.0145 (UTC) FILETIME=[B4B97E10:01C99C28] Cc: idr List , Danny McPherson Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:52:07 -0000 On Mar 3, 2009, at 12:44 PM, Robert Raszuk wrote: > Hi John, > > It's so great to be in sync ! > > > To reiterate, "silent update drop" isn't the intent of the draft and > > we'll strive to make this even clearer in the next version. > > I would just propose a one sentence to be added to make it cristal > clear ... > > "If due to an errors, including those propagated in transitive > attributes, the other attributes of the update message can not be > correctly parsed the entire update is considered invalid and > procedures of [RFC4271] continue to apply. I'll add that or something like it. > that would clearly contradict with the text below which perhaps > needs to be re-edited a bit too. > > >> The draft says: "In any case, an error in an optional transitive > >> attribute whose Partial bit is set MUST NOT be responded to by > >> sending a NOTIFICATION message or resetting the BGP session." I think your concern would be addressed by a simple change: s/in/ limited to/, so: "In any case, an error limited to an optional transitive attribute whose Partial bit is set MUST NOT be responded to by sending a NOTIFICATION message or resetting the BGP session." Agree? Thanks, --John From robert@raszuk.net Tue Mar 3 10:43:13 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B73028C0E7 for ; Tue, 3 Mar 2009 10:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AVacmvxj-NM for ; Tue, 3 Mar 2009 10:43:12 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id C31C93A6C57 for ; Tue, 3 Mar 2009 10:43:10 -0800 (PST) Received: (qmail 27239 invoked by uid 399); 3 Mar 2009 18:43:37 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.4.248) by mail37.opentransfer.com with SMTP; 3 Mar 2009 18:43:37 -0000 Message-ID: <49AD7A57.4020206@raszuk.net> Date: Tue, 03 Mar 2009 10:43:35 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "John G. Scudder" References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> <49AD024D.5030902@raszuk.net> <49AD4B34.6050209@raszuk.net> <5C5A67FB-FA71-44D9-8772-EE46F543A571@juniper.net> <49AD6C89.1050604@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr List , Danny McPherson Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 18:43:13 -0000 Hi John, >> "If due to an errors, including those propagated in transitive >> attributes, the other attributes of the update message can not be >> correctly parsed the entire update is considered invalid and >> procedures of [RFC4271] continue to apply. > > I'll add that or something like it. Thx ! >> that would clearly contradict with the text below which perhaps needs >> to be re-edited a bit too. >> >> >> The draft says: "In any case, an error in an optional transitive >> >> attribute whose Partial bit is set MUST NOT be responded to by >> >> sending a NOTIFICATION message or resetting the BGP session." > > I think your concern would be addressed by a simple change: s/in/limited > to/, so: "In any case, an error limited to an optional transitive > attribute whose Partial bit is set MUST NOT be responded to by sending a > NOTIFICATION message or resetting the BGP session." Agree? Well if you want to massage this sentence to make it sound right one would need to also mention that this applies only if such an error limited to given transitive attribute has no impact on routes. For example transitive ext community route target attribute can not be just dropped as vpnv4 routes in an implicit withdraw propagated further would be of quite a limited use. Cheers, R. From jgs@juniper.net Tue Mar 3 12:46:22 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5300B3A69CE for ; Tue, 3 Mar 2009 12:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOc87Zwtrbby for ; Tue, 3 Mar 2009 12:46:21 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 62B593A684A for ; Tue, 3 Mar 2009 12:46:21 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSa2XONMsRT1C/ixNzNb5QsoC+VoL1VWe@postini.com; Tue, 03 Mar 2009 12:46:49 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 3 Mar 2009 12:45:50 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 12:45:50 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 12:45:50 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 12:45:49 -0800 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n23KjnM64175 for ; Tue, 3 Mar 2009 12:45:49 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: <2454DC8C-0B03-45F8-86A6-93ACF01AEAF4@juniper.net> From: "John G. Scudder" To: idr List Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 15:45:48 -0500 References: <20090303204347.478E23A689E@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Mar 2009 20:45:49.0940 (UTC) FILETIME=[0949AB40:01C99C41] Subject: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 20:46:22 -0000 FYI. This version includes clarifications based on suggestions from several WG members. URL: http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-01.txt --John Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 3, 2009 3:43:47 PM GMT-05:00 > To: jgs@juniper.net > Cc: enkechen@cisco.com > Subject: New Version Notification for draft-scudder-idr-optional- > transitive-01 > > > A new version of I-D, draft-scudder-idr-optional-transitive-01.txt > has been successfuly submitted by John Scudder and posted to the > IETF repository. > > Filename: draft-scudder-idr-optional-transitive > Revision: 01 > Title: Error Handling for Optional Transitive BGP Attributes > Creation_date: 2009-03-03 > WG ID: Independent Submission > Number_of_pages: 8 > > 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 in the case of optional transitive > attributes. This document revises BGP's error-handling rules for > optional transitive attributes, and provides guidelines for the > authors of documents defining new optional transitive attributes. It > also revises the error handling procedures for several existing > optional transitive attributes. > > > > The IETF Secretariat. > > From narten@us.ibm.com Tue Mar 3 16:09:21 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B7328C2AC for ; Tue, 3 Mar 2009 16:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgMPCZ2QDf6u for ; Tue, 3 Mar 2009 16:09:20 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 4995928C15E for ; Tue, 3 Mar 2009 16:09:20 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e7.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2401FbT001922 for ; Tue, 3 Mar 2009 19:01:15 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2409l9I193370 for ; Tue, 3 Mar 2009 19:09:47 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2409kp5026344 for ; Tue, 3 Mar 2009 19:09:46 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-251-16.mts.ibm.com [9.65.251.16]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2409je6026287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2009 19:09:46 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n2409icS031817; Tue, 3 Mar 2009 18:09:45 -0600 Message-Id: <200903040009.n2409icS031817@cichlid.raleigh.ibm.com> To: robert@raszuk.net In-reply-to: <49ACFA4C.4060609@raszuk.net> References: <200902180028.n1I0S4M39842@magenta.juniper.net> <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> <49ACFA4C.4060609@raszuk.net> Comments: In-reply-to Robert Raszuk message dated "Tue, 03 Mar 2009 01:37:16 -0800." Date: Tue, 03 Mar 2009 18:09:44 -0600 From: Thomas Narten Cc: idr@ietf.org Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 00:09:21 -0000 Robert, > Since the original draft's publication date June 2003 (well even earlier > as I started to discuss this idea with Pedro Marques around beg of 2003 > if not earlier) I was fully aware about Juniper's authors filing the > patent application for this work. There was no mystery of any sort made > reg this filing. Hmm. Why did you not then file a 3rd party IPR disclosure? > That was and still is the common industry practice in any vendor for any > novel work which is going to be publicly presented. AFAIK you can safely > assume that vast majority of IETF drafts have patents filed behind. The > fact that some lawyers did not disclosed it on time is regrettable, but > should not be a point of any discussion in IDR WG. The obligation is not on lawyers to disclose, it is on IETF _participants_ (called "Contributers in RFC 3979). This is absolutely clear in RFC 3979. > As I recommended already before if such disclosures are so important > IETF should add a mandatory section of any draft template or mandatory > field on the draft submission page to list them or explicitly state > "none". You may want to consult with a lawyer. There is boilerplate text included in all IDs that says you understand the IETF rules (including those w.r.t IPR). I.e., submitting an ID with the following text: This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. has real legal implications. Ignorence is no excuse and all that. Same goes for "NOTE WELL" text that you have to acknowledge on a regular basis. > Having the draft publishing and IPR disclosures submission taking > totally independent paths as it is today is just a clear receipt for > more cases like this one to happen. Sorry, I don't buy this. The IETF has had many discussions over many years about how to ensure that participants know their obligations w.r.t. IPR. The processes/rules we have adopted are designed to protect the IETF and _all_ of its participants. The IETF has even received legal advice on how to construct its rules and to adequately notify participants of their obligations. IETF participants are obligated to follow the rules. If they chose not to, they expose themselves (and their employers) to potential legal risk. For example, they may find that by not disclosing, they are later unable to enforce the patents they have obtained. Consult your own lawyer please if you disagree. The IETF IPR rules were designed to protect the IETF process and they were designed with such scenarios as participants acting in "bad faith" when it comes to disclosing IPR. Thomas From robert@raszuk.net Tue Mar 3 16:28:25 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49653A6814 for ; Tue, 3 Mar 2009 16:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf4kvebOW0-V for ; Tue, 3 Mar 2009 16:28:25 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id EF79D3A67B4 for ; Tue, 3 Mar 2009 16:28:24 -0800 (PST) Received: (qmail 4595 invoked by uid 399); 4 Mar 2009 00:28:52 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.4.248) by mail37.opentransfer.com with SMTP; 4 Mar 2009 00:28:52 -0000 Message-ID: <49ADCB41.20001@raszuk.net> Date: Tue, 03 Mar 2009 16:28:49 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Thomas Narten References: <200902180028.n1I0S4M39842@magenta.juniper.net> <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> <49ACFA4C.4060609@raszuk.net> <200903040009.n2409icS031817@cichlid.raleigh.ibm.com> In-Reply-To: <200903040009.n2409icS031817@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 00:28:26 -0000 Hi Thomas, > Hmm. Why did you not then file a 3rd party IPR disclosure? > >> That was and still is the common industry practice in any vendor for any >> novel work which is going to be publicly presented. AFAIK you can safely >> assume that vast majority of IETF drafts have patents filed behind. The >> fact that some lawyers did not disclosed it on time is regrettable, but >> should not be a point of any discussion in IDR WG. > > The obligation is not on lawyers to disclose, it is on IETF > _participants_ (called "Contributers in RFC 3979). This is absolutely > clear in RFC 3979. RFC3979 date is 2005. For this particular draft we are talking about draft preparation which tool place in 2002/2003. >> Having the draft publishing and IPR disclosures submission taking >> totally independent paths as it is today is just a clear receipt for >> more cases like this one to happen. > > Sorry, I don't buy this. The IETF has had many discussions over many > years about how to ensure that participants know their obligations > w.r.t. IPR. The processes/rules we have adopted are designed to > protect the IETF and _all_ of its participants. I was not trying to say that adopted processes/rules are bad. I was just gently trying to suggest how to make it more effective in practice. Cheers, R. From john@jlc.net Tue Mar 3 18:35:37 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1410228C26A for ; Tue, 3 Mar 2009 18:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.126 X-Spam-Level: X-Spam-Status: No, score=-5.126 tagged_above=-999 required=5 tests=[AWL=1.473, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZnKB4N7-eA1 for ; Tue, 3 Mar 2009 18:35:36 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 366CB28C250 for ; Tue, 3 Mar 2009 18:35:36 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8256333C34; Tue, 3 Mar 2009 21:36:04 -0500 (EST) Date: Tue, 3 Mar 2009 21:36:04 -0500 From: John Leslie To: Robert Raszuk Message-ID: <20090304023604.GW65762@verdi> References: <200902180028.n1I0S4M39842@magenta.juniper.net> <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> <49ACFA4C.4060609@raszuk.net> <200903040009.n2409icS031817@cichlid.raleigh.ibm.com> <49ADCB41.20001@raszuk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49ADCB41.20001@raszuk.net> User-Agent: Mutt/1.4.1i Cc: idr@ietf.org Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 02:35:37 -0000 Robert Raszuk wrote: > Thomas Narten wrote: >> Robert Raszuk wrote: >> >>> That was and still is the common industry practice in any vendor for >>> any novel work which is going to be publicly presented. AFAIK you >>> can safely assume that vast majority of IETF drafts have patents >>> filed behind. The numbers don't support this. Counting just RFCs, there are substantially more RFCs than disclosures; and there are _far_ more I-Ds than RFCs. (Though the IDR WG _may_ have a different balance...) >>> The fact that some lawyers did not disclosed it on time is >>> regrettable, but should not be a point of any discussion in IDR WG. Alas, this is exactly where it _should_ be discussed. (And I think you'll find the discussion here more friendly than most of the other options.) >> The obligation is not on lawyers to disclose, it is on IETF >> _participants_ (called "Contributers in RFC 3979). This is absolutely >> clear in RFC 3979. Note particularly Section 7: ] ] There are cases where individuals are not permitted by their ] employers or by other factors to disclose the existence or substance ] of patent applications or other IPR. Since disclosure is required ] for anyone submitting documents or participating in IETF discussions, ] a person who does not disclose IPR for this reason, or any other ] reason, must not contribute to or participate in IETF activities with ] respect to technologies that he or she reasonably and personally ] knows to be Covered by IPR which he or she will not disclose. ] Contributing to or participating in IETF discussions about a ] technology without making required IPR disclosures is a violation of ] IETF process. > RFC3979 date is 2005. For this particular draft we are talking about > draft preparation which tool place in 2002/2003. Actually, the appropriate language for 2003 gave you even less wiggle room. RFC3979 allws you: ] ] The IPR disclosure... must be made as soon as reasonably possible ] after the Contribution is published in an Internet Draft... which your lawyers will perhaps happily stretch to five years. (I wouldn't suggest pushing it quite that far in this WG, though.) Frankly, I doubt even your lawyers would seriously argue that Section 7 of RFC3979 didn't apply to your participation after 3979 was published just because an initial I-D was published before then. (YMMV, I suppose...) -- John Leslie From rjs@eng.gxn.net Wed Mar 4 04:33:54 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860F63A6C66 for ; Wed, 4 Mar 2009 04:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P97t2oaJk5ZV for ; Wed, 4 Mar 2009 04:33:53 -0800 (PST) Received: from mx01.eng.pipex.net (mx01.eng.pipex.net [212.241.168.204]) by core3.amsl.com (Postfix) with ESMTP id 2A66A3A6B91 for ; Wed, 4 Mar 2009 04:32:51 -0800 (PST) Received: from bronze.eng.gxn.net (bronze.eng.gxn.net [212.241.168.68]) by mx01.eng.pipex.net (8.13.8/8.11.2) with ESMTP id n24CXFAq019478; Wed, 4 Mar 2009 12:33:17 GMT X-Envelope-From: rjs@eng.gxn.net Received: (from rjs@localhost) by bronze.eng.gxn.net (8.13.1/8.13.1) id n24CXDTq024668; Wed, 4 Mar 2009 12:33:13 GMT X-Authentication-Warning: bronze.eng.gxn.net: rjs set sender to rjs@eng.gxn.net using -f Date: Wed, 4 Mar 2009 12:33:12 +0000 From: Rob Shakir To: "John G. Scudder" Message-ID: <20090304123312.GA29001@bronze.eng.gxn.net> References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> <49AD024D.5030902@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mx01.eng.pipex.net [212.241.168.204]); Wed, 04 Mar 2009 12:33:18 +0000 (GMT) Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 12:33:54 -0000 On Tue, Mar 03, 2009 at 09:00:15AM -0500, John G. Scudder wrote: > I'd be interested in feedback from the WG regarding the question of > withdrawing the routes (what the draft proposes) vs. dropping the > session (current behavior). Especially feedback from network operators. John, Thanks very much for the work on this draft by Enke and yourself. >From my perspective (and I think a number of other operators that I have spoken with), the approach of treating the invalid update as a withdraw of the routes within it is the best way to handle this problem -- as I posted to the list earlier in the year. Whilst I think that there is perhaps scope for comments on this draft that ask for this behaviour to be extended to all optional transitive attributes, rather than just those with the partial bit set, I do not think that this is the best way forward on this matter. The major operational problem with tunneled attributes (as well as the security implications), is that the operator does not have a direct relationship with the party that has caused the session to be torn down -- any errors in a direct neighbour's BGP implementation can generally be addressed by existing communication channels with the neighbouring AS, and hence a comparitively easier to resolve. With regards to the question posed earlier in this thread as to whether it is preferable to see session teardown, or 99% of the prefixes on this session withdrawn, I would definitely lean towards the prefixes being withdrawn. The reasoning is even clearer when taking the opposite extreme -- a single prefix tearing down a session carrying the global table. In this case, the impact to the network that receives this update is that we lose visibility of the global BGP table (by one of our paths at least), rather than just 'punishing' a single prefix with unreachability. Operationally -- I think that any 'harmful' implications of this issue are well-handled by section 3 -- the requirement to provide debugging features should allow operators to easily identify why this prefix has been withdrawn. It is also worth considering the number of scenarios in which the prefix will become completely unreachable from a multi-homed network -- I believe that this will be rare in practice. Once again -- thanks for the work on this. Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html From narten@us.ibm.com Wed Mar 4 12:51:12 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F18E3A6923 for ; Wed, 4 Mar 2009 12:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOFT1rmGlUCj for ; Wed, 4 Mar 2009 12:51:11 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 38C6B3A67A7 for ; Wed, 4 Mar 2009 12:51:11 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n24KnBif015885 for ; Wed, 4 Mar 2009 15:49:11 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n24Kpch6180832 for ; Wed, 4 Mar 2009 15:51:38 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n24KoKF3023878 for ; Wed, 4 Mar 2009 15:50:20 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-207-110.mts.ibm.com [9.65.207.110]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n24KoJ0F023777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 15:50:20 -0500 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n24KpZwZ005739; Wed, 4 Mar 2009 14:51:36 -0600 Message-Id: <200903042051.n24KpZwZ005739@cichlid.raleigh.ibm.com> To: robert@raszuk.net In-reply-to: <49ADCB41.20001@raszuk.net> References: <200902180028.n1I0S4M39842@magenta.juniper.net> <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> <49ACFA4C.4060609@raszuk.net> <200903040009.n2409icS031817@cichlid.raleigh.ibm.com> <49ADCB41.20001@raszuk.net> Comments: In-reply-to Robert Raszuk message dated "Tue, 03 Mar 2009 16:28:49 -0800." Date: Wed, 04 Mar 2009 14:51:35 -0600 From: Thomas Narten Cc: idr@ietf.org Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 20:51:12 -0000 Robert Raszuk writes: > > Hmm. Why did you not then file a 3rd party IPR disclosure? > > > >> That was and still is the common industry practice in any vendor for any > >> novel work which is going to be publicly presented. AFAIK you can safely > >> assume that vast majority of IETF drafts have patents filed behind. The > >> fact that some lawyers did not disclosed it on time is regrettable, but > >> should not be a point of any discussion in IDR WG. > > > > The obligation is not on lawyers to disclose, it is on IETF > > _participants_ (called "Contributers in RFC 3979). This is absolutely > > clear in RFC 3979. > RFC3979 date is 2005. For this particular draft we are talking about > draft preparation which tool place in 2002/2003. In 2002, the relevant IPR RFC would have been RFC 2026 (dated 1996). It says: 6. The contributor represents that he has disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the contributor. The contributor does not represent that he personally knows of all potentially pertinent proprietary and intellectual property rights owned or claimed by the organization he represents (if any) or third parties. The obligation to disclose IPR is hardly new and certainly applied to the authors of the draft in question in 2002. Thomas From dward@cisco.com Wed Mar 4 14:40:18 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1DA28C173 for ; Wed, 4 Mar 2009 14:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGf4nVVPITGd for ; Wed, 4 Mar 2009 14:40:17 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A764C28C1A3 for ; Wed, 4 Mar 2009 14:40:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,303,1233532800"; d="scan'208";a="261481507" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 04 Mar 2009 22:40:39 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n24MedQ4001578; Wed, 4 Mar 2009 17:40:39 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n24MedL1014724; Wed, 4 Mar 2009 22:40:39 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 17:40:39 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 17:40:39 -0500 Message-Id: <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> From: David Ward To: Yakov Rekhter In-Reply-To: <200902180030.n1I0UiM41233@magenta.juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 4 Mar 2009 16:40:38 -0600 References: <200902180030.n1I0UiM41233@magenta.juniper.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 04 Mar 2009 22:40:39.0324 (UTC) FILETIME=[3E17FDC0:01C99D1A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2049; t=1236206439; x=1237070439; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[Idr]=20WG=20Last=20Call=20on=20draft-i etf-idr-flow-spec-05.txt |Sender:=20 |To:=20Yakov=20Rekhter=20; bh=mfUqZjTe8RxXZOhQcEsY9I9NAsm0S2eOq5X6OSoJzY4=; b=X3TQ8HzynSfWL3eKJQtKB6QUZvVd3SMxjzPlbbL9M+i27GifrH0oo5zREm 83dA4uMyuChppn6uPvFOBbw3R80BbImVH/0e0FyaU2jacxrSJS64uNEs78AK WuTMoIKR5Z; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Ross Callon , idr@ietf.org, David Ward Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 22:40:18 -0000 Sue, Yakov - This deadline has come and gone with zero comments on the re-LC of this draft. Given the comments and discussion on IPR disclosures on the IDR list in general, I (and the IESG) need a more concrete sign that the WG has consensus that the document should continue to progress towards publication. ------------ Related to IPR, I strongly encourage all IETF participants to read and understand: http://www.ietf.org/overview.html (read and understand the NOTE WELL) http://www.ietf.org/rfc/rfc3979.txt?number=3979 http://www.ietf.org/rfc/rfc4879.txt I refer the WG to these documents and pointers as well: http://www.ietf.org/rfc/rfc3669.txt?number=3669 https://datatracker.ietf.org/ipr/ http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF72/72newcomers.ppt (page 48 - 56) Newcomer's training at the upcoming IETF held by the edu team on Sunday 2009.03.22 at 1300 in Imperial B (see https://datatracker.ietf.org/meeting/74/agenda.txt for any changes) If you have difficulty keeping up with IPR disclosures, here is an RSS feed of all IETF IPR disclosures: feed:https://datatracker.ietf.org/feed/ipr/ If you believe that you'd like the ADs to spend some time in the RTGAREA WG meeting to provide some education on IPR issues, rule, requirements, etc at the IETF please contact us privately or mailto:rtg-ads@tools.ietf.org Thanks and hope it helps. -DWard On Feb 17, 2009, at 6:30 PM, Yakov Rekhter wrote: > Folks, > > Given the recent IPR disclosure (https://datatracker.ietf.org/ipr/ > 1088) > associated with the flow-spec draft > (http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-05.txt ) > we are going to re-WG-LC the document and rerun the publication > process. > > The deadline for comments is 3/2/2009. > > Sue & Yakov. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From tony.li@tony.li Wed Mar 4 15:03:55 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB163A6CA9 for ; Wed, 4 Mar 2009 15:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loZ4YA9RNiDJ for ; Wed, 4 Mar 2009 15:03:54 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id C72F23A6AE5 for ; Wed, 4 Mar 2009 15:02:48 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA05.westchester.pa.mail.comcast.net with comcast id P31b1b0170SCNGk55B3J3Y; Wed, 04 Mar 2009 23:03:18 +0000 Received: from [127.0.0.1] ([192.76.146.160]) by OMTA09.westchester.pa.mail.comcast.net with comcast id PB2q1b00e3TrxM43VB35et; Wed, 04 Mar 2009 23:03:16 +0000 Message-ID: <49AF086C.5060601@tony.li> Date: Wed, 04 Mar 2009 15:02:04 -0800 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Ward References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> In-Reply-To: <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:03:55 -0000 David Ward wrote: > Sue, Yakov - > > This deadline has come and gone with zero comments on the re-LC of this > draft. Given the comments and discussion on IPR disclosures on the IDR > list in general, I (and the IESG) need a more concrete sign that the WG > has consensus that the document should continue to progress towards > publication. I feel that the document, while technically worthy, should not progress given these IPR claims. Please note that this is my blanket policy on any technology with outstanding IPR claims without royalty-free licensing, and is not specific to this work, its authors, or the employer's of the authors. Regards, Tony From rcallon@juniper.net Wed Mar 4 15:25:44 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38FD28C3B7 for ; Wed, 4 Mar 2009 15:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs998dlKdjLj for ; Wed, 4 Mar 2009 15:25:44 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id E105328C395 for ; Wed, 4 Mar 2009 15:25:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSa8N/0K/Wk8iQCzcz09Jes8r0BXMZier@postini.com; Wed, 04 Mar 2009 15:26:13 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Wed, 4 Mar 2009 15:25:31 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 15:25:30 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 15:25:30 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 18:25:20 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05D44EBA@emailwf1.jnpr.net> In-Reply-To: <49AF086C.5060601@tony.li> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt Thread-Index: AcmdHX7OFUS7IYV2TFaWU+GuD9QLdAAAX0XA References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <49AF086C.5060601@tony.li> From: Ross Callon To: "Tony Li" X-OriginalArrivalTime: 04 Mar 2009 23:25:30.0485 (UTC) FILETIME=[82269250:01C99D20] Cc: Yakov Rekhter , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:25:44 -0000 I assume that this discussion is about the recent Juniper disclosure (if there is another disclosure from another company please let me know). The terms that are in the Juniper IPR disclosure include (I just got this by googling the disclosure): If this standard is adopted, Juniper will not assert any patents owned or controlled by Juniper against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Juniper retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Juniper or any of Juniper's affiliates or successors in title or against any products of Juniper or any products of any of Juniper's affiliates either alone or in combination with other products; and Juniper retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard. Isn't this the legal words for "free if you don't try to inflict your IPR against us"? I am pretty sure that these words were pretty much copied from IPR disclosures to the IETF by other companies.=20 I don't see how this contradicts your desire for "royalty-free licensing".=20 I do see that there would be some advantage in having the IETF come up with preferred IETF words for disclosures with the goal of "free if you don't try to inflict your IPR against us". However, agreeing to words that we all like would be pretty obviously outside of the scope of IDR.=20 Ross -----Original Message----- From: Tony Li [mailto:tony.li@tony.li]=20 Sent: 04 March 2009 18:02 To: David Ward Cc: Yakov Rekhter; Ross Callon; idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt David Ward wrote: > Sue, Yakov - >=20 > This deadline has come and gone with zero comments on the re-LC of this=20 > draft. Given the comments and discussion on IPR disclosures on the IDR > list in general, I (and the IESG) need a more concrete sign that the WG=20 > has consensus that the document should continue to progress towards=20 > publication. I feel that the document, while technically worthy, should not progress=20 given these IPR claims. Please note that this is my blanket policy on any technology with=20 outstanding IPR claims without royalty-free licensing, and is not=20 specific to this work, its authors, or the employer's of the authors. Regards, Tony From robert@raszuk.net Wed Mar 4 15:30:06 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14D328C434 for ; Wed, 4 Mar 2009 15:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBa1COJbSo2M for ; Wed, 4 Mar 2009 15:30:05 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 1C8BC28C433 for ; Wed, 4 Mar 2009 15:30:05 -0800 (PST) Received: (qmail 9566 invoked by uid 399); 4 Mar 2009 23:30:33 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.39.80) by mail37.opentransfer.com with SMTP; 4 Mar 2009 23:30:33 -0000 Message-ID: <49AF0F16.4040900@raszuk.net> Date: Wed, 04 Mar 2009 15:30:30 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ross Callon References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <49AF086C.5060601@tony.li> <3525C9833C09ED418C6FD6CD9514668C05D44EBA@emailwf1.jnpr.net> In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C05D44EBA@emailwf1.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , Tony Li , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:30:07 -0000 Ross, Ref: https://datatracker.ietf.org/ipr/1106/ It says: "Royalty-bearing licenses will be available to anyone who prefers that option." Cheers, R. > I assume that this discussion is about the recent Juniper disclosure (if > there is another disclosure from another company please let me know). > The terms that are in the Juniper IPR disclosure include (I just got > this by googling the disclosure): > > If this standard is adopted, Juniper will not assert any patents > owned > or controlled by Juniper against any party for making, using, > selling, > importing or offering for sale a product that implements the > standard, > provided, however that Juniper retains the right to assert its > patents > (including the right to claim past royalties) against any party > that > asserts a patent it owns or controls (either directly or > indirectly) > against Juniper or any of Juniper's affiliates or successors in > title or against any products of Juniper or any products of any of > Juniper's > affiliates either alone or in combination with other products; > and > Juniper retains the right to assert its patents against any > product or > portion thereof that is not necessary for compliance with the > standard. > > Isn't this the legal words for "free if you don't try to inflict your > IPR against us"? I am pretty sure that these words were pretty much > copied from IPR disclosures to the IETF by other companies. > > I don't see how this contradicts your desire for "royalty-free > licensing". > > I do see that there would be some advantage in having the IETF come up > with preferred IETF words for disclosures with the goal of "free if you > don't try to inflict your IPR against us". However, agreeing to words > that we all like would be pretty obviously outside of the scope of IDR. > > Ross > > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li] > Sent: 04 March 2009 18:02 > To: David Ward > Cc: Yakov Rekhter; Ross Callon; idr@ietf.org > Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt > > David Ward wrote: >> Sue, Yakov - >> >> This deadline has come and gone with zero comments on the re-LC of > this >> draft. Given the comments and discussion on IPR disclosures on the IDR > >> list in general, I (and the IESG) need a more concrete sign that the > WG >> has consensus that the document should continue to progress towards >> publication. > > > I feel that the document, while technically worthy, should not progress > given these IPR claims. > > Please note that this is my blanket policy on any technology with > outstanding IPR claims without royalty-free licensing, and is not > specific to this work, its authors, or the employer's of the authors. > > Regards, > Tony > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From robert@raszuk.net Wed Mar 4 15:30:30 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6115528C454 for ; Wed, 4 Mar 2009 15:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKLQ5OuV4TSJ for ; Wed, 4 Mar 2009 15:30:29 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 0364228C450 for ; Wed, 4 Mar 2009 15:30:28 -0800 (PST) Received: (qmail 9927 invoked by uid 399); 4 Mar 2009 23:30:57 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.39.80) by mail37.opentransfer.com with SMTP; 4 Mar 2009 23:30:57 -0000 Message-ID: <49AF0F2E.70307@raszuk.net> Date: Wed, 04 Mar 2009 15:30:54 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tony Li References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <49AF086C.5060601@tony.li> In-Reply-To: <49AF086C.5060601@tony.li> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Yakov Rekhter , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:30:30 -0000 Hi Tony, There seems to six basic types of licensing: – Royalty-free license of right – Royalty-bearing license of right – Royalty-free discretionary license – Royalty-bearing discretionary license – Royalty-free voluntary license – Royalty-bearing voluntary license The draft in question is disclosed as "royalty-bearing license of right". The same terms are used in many other disclosures from many vendors with drafts and RFCs already in place. I think as co-author of this draft I agree with your opinion and I hope it can be re-disclosed as royalty-free. That would make it fully complaint with rfc3979 expectations. Many thx, R. > David Ward wrote: >> Sue, Yakov - >> >> This deadline has come and gone with zero comments on the re-LC of >> this draft. Given the comments and discussion on IPR disclosures on >> the IDR list in general, I (and the IESG) need a more concrete sign >> that the WG has consensus that the document should continue to >> progress towards publication. > > I feel that the document, while technically worthy, should not progress > given these IPR claims. > > Please note that this is my blanket policy on any technology with > outstanding IPR claims without royalty-free licensing, and is not > specific to this work, its authors, or the employer's of the authors. > > Regards, > Tony > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From tony.li@tony.li Wed Mar 4 15:39:15 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03FFA28C0CF for ; Wed, 4 Mar 2009 15:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX5KYBRF-iAN for ; Wed, 4 Mar 2009 15:39:14 -0800 (PST) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id D70443A6B2E for ; Wed, 4 Mar 2009 15:39:10 -0800 (PST) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id P7fc1b0041HpZEsA4BfgHu; Wed, 04 Mar 2009 23:39:40 +0000 Received: from [127.0.0.1] ([192.76.146.160]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id PBfC1b00F3TrxM48aBfT5C; Wed, 04 Mar 2009 23:39:38 +0000 Message-ID: <49AF10F0.4090608@tony.li> Date: Wed, 04 Mar 2009 15:38:24 -0800 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ross Callon References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <49AF086C.5060601@tony.li> <3525C9833C09ED418C6FD6CD9514668C05D44EBA@emailwf1.jnpr.net> In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C05D44EBA@emailwf1.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:39:15 -0000 Hi Ross, > Isn't this the legal words for "free if you don't try to inflict your > IPR against us"? I am pretty sure that these words were pretty much > copied from IPR disclosures to the IETF by other companies. > > I don't see how this contradicts your desire for "royalty-free > licensing". The problem is that this is just suspended royalties, not truly royalty-free. Even with the defensive clause, it implies that there is a future quid-pro-quo. Imagine company A provides technology X under these terms. Now, company B comes along and implements X. In the meantime, A discovers this and intentionally infringes B's IPR on technology Y. If B sues A for intentional infringement on Y, then A sues B over X. How is that fair? If companies are going to be altruistic and contribute to the standards process, then they should simply contribute. If not, they should stay home and stay proprietary. Under the IETF rules, the WG gets to decide on how to proceed and given that we can live without this technology, I would prefer to simply pass on it. Nothing personal all around. Regards, Tony From rcallon@juniper.net Wed Mar 4 16:09:25 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04823A69E2 for ; Wed, 4 Mar 2009 16:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M0R5zLmFFOm for ; Wed, 4 Mar 2009 16:09:24 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id CC65D3A68D1 for ; Wed, 4 Mar 2009 16:09:24 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSa8YS1k5FXhbb1M6DRcMQAxB1DVXgG8s@postini.com; Wed, 04 Mar 2009 16:09:54 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Wed, 4 Mar 2009 16:07:55 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 16:07:55 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 16:07:54 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 19:07:51 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05D44ED5@emailwf1.jnpr.net> In-Reply-To: <49AF10F0.4090608@tony.li> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt Thread-Index: AcmdIoazrkYv8xlYT8O6nvyFX/RymgAAVP6g References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <49AF086C.5060601@tony.li> <3525C9833C09ED418C6FD6CD9514668C05D44EBA@emailwf1.jnpr.net> <49AF10F0.4090608@tony.li> From: Ross Callon To: "Tony Li" X-OriginalArrivalTime: 05 Mar 2009 00:07:54.0909 (UTC) FILETIME=[6EBEDCD0:01C99D26] Cc: Yakov Rekhter , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 00:09:25 -0000 The problem with your argument is that companies that did not contribute to the work almost certainly have filed patents on at least the same idea (whether motivated by this work, or independent of it). Thus, if the people who actually do the work in the IETF say "we give up all rights to patents that we have on this work", then the other companies, who did not contribute, can go to court and say that they own the technology (since they also have patents on the same thing, and they didn't give up their rights since they didn't need to because they didn't contribute the work -- even if they were sitting in the back of the room at the time).=20 To me the right result of standards is that any company can use the resulting standards without royalty. The text in this disclosure is the closest that I have seen (I am not a lawyer) to allowing anyone to use the standard without any royalty. What you are proposing would defeat this, specifically by requiring companies who did the work to pay royalties to companies or people who did not do the work. This would be a severe disincentive to anyone who would consider contributing to IETF efforts in the future. A related point is that the words in this disclosure are almost identical (the company name has been changed) from multiple other disclosures by other companies related to different documents. The IETF has lots of standards that are covered by disclosures just like this one. Should we remove all of them?=20 In your example, if we believe in standards, and if the technologies are closely related, then X and Y should both be standardized in the IETF, and both should be subject to the same "don't sue us and you can use it for free" terms.=20 Ross -----Original Message----- From: Tony Li [mailto:tony.li@tony.li]=20 Sent: 04 March 2009 18:38 To: Ross Callon Cc: Yakov Rekhter; idr@ietf.org; David Ward Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt Hi Ross, > Isn't this the legal words for "free if you don't try to inflict your > IPR against us"? I am pretty sure that these words were pretty much > copied from IPR disclosures to the IETF by other companies.=20 >=20 > I don't see how this contradicts your desire for "royalty-free > licensing".=20 The problem is that this is just suspended royalties, not truly=20 royalty-free. Even with the defensive clause, it implies that there is=20 a future quid-pro-quo. Imagine company A provides technology X under these terms. Now, company B comes along and implements X. In the meantime, A discovers this and=20 intentionally infringes B's IPR on technology Y. If B sues A for=20 intentional infringement on Y, then A sues B over X. How is that fair? If companies are going to be altruistic and contribute to the standards=20 process, then they should simply contribute. If not, they should stay=20 home and stay proprietary. Under the IETF rules, the WG gets to decide on how to proceed and given=20 that we can live without this technology, I would prefer to simply pass=20 on it. Nothing personal all around. Regards, Tony From tony.li@tony.li Wed Mar 4 21:54:36 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D727D3A695E for ; Wed, 4 Mar 2009 21:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUyKkOh3ihfo for ; Wed, 4 Mar 2009 21:54:35 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 489B13A67FF for ; Wed, 4 Mar 2009 21:54:35 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA08.westchester.pa.mail.comcast.net with comcast id PHpZ1b0030bG4ec58Hv4Rh; Thu, 05 Mar 2009 05:55:04 +0000 Received: from [127.0.0.1] ([192.76.146.160]) by OMTA03.westchester.pa.mail.comcast.net with comcast id PHuR1b0073TrxM43PHufVD; Thu, 05 Mar 2009 05:54:49 +0000 Message-ID: <49AF68DB.2090306@tony.li> Date: Wed, 04 Mar 2009 21:53:31 -0800 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ross Callon References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <49AF086C.5060601@tony.li> <3525C9833C09ED418C6FD6CD9514668C05D44EBA@emailwf1.jnpr.net> <49AF10F0.4090608@tony.li> <3525C9833C09ED418C6FD6CD9514668C05D44ED5@emailwf1.jnpr.net> In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C05D44ED5@emailwf1.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 05:54:38 -0000 Hi Ross, Ross Callon wrote: > The problem with your argument is that companies that did not contribute > to the work almost certainly have filed patents on at least the same > idea (whether motivated by this work, or independent of it). Thus, if > the people who actually do the work in the IETF say "we give up all > rights to patents that we have on this work", then the other companies, > who did not contribute, can go to court and say that they own the > technology (since they also have patents on the same thing, and they > didn't give up their rights since they didn't need to because they > didn't contribute the work -- even if they were sitting in the back of > the room at the time). This assumes that everyone has patents on everything. In any sane (stipulate optimism) world, only one of those is valid. Further, I'm not suggesting that folks give up their rights. Rather, they give royalty-free licenses. > To me the right result of standards is that any company can use the > resulting standards without royalty. The text in this disclosure is the > closest that I have seen (I am not a lawyer) to allowing anyone to use > the standard without any royalty. What you are proposing would defeat > this, specifically by requiring companies who did the work to pay > royalties to companies or people who did not do the work. This would be > a severe disincentive to anyone who would consider contributing to IETF > efforts in the future. We share the goal, but we disagree on the outcome. The only ones who get paid are those that have valid claims and did not participate. Can't stop those folks anyhow... > A related point is that the words in this disclosure are almost > identical (the company name has been changed) from multiple other > disclosures by other companies related to different documents. The IETF > has lots of standards that are covered by disclosures just like this > one. Should we remove all of them? As Dave points out, I've opposed all of them equally. ;-) While I'm not Quixotic enough to undo water under the bridge, I'm still more than happy to add to the set. > In your example, if we believe in standards, and if the technologies are > closely related, then X and Y should both be standardized in the IETF, > and both should be subject to the same "don't sue us and you can use it > for free" terms. Or... both should just be royalty-free. Same outcome. ;-) Tony From yakov@juniper.net Thu Mar 5 07:48:32 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E556F28C10E for ; Thu, 5 Mar 2009 07:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opyQuIRaWZ1H for ; Thu, 5 Mar 2009 07:48:31 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id ADB5C3A69F2 for ; Thu, 5 Mar 2009 07:48:31 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSa/0bavU6IM3gb6wL30LhP+JZUUQm2+4@postini.com; Thu, 05 Mar 2009 07:49:01 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 5 Mar 2009 07:47:36 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 07:47:36 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 07:47:36 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 07:47:35 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n25FlZM96518; Thu, 5 Mar 2009 07:47:35 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200903051547.n25FlZM96518@magenta.juniper.net> To: idr@ietf.org, rcallon@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <39352.1236268055.1@juniper.net> Date: Thu, 5 Mar 2009 07:47:35 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 05 Mar 2009 15:47:35.0819 (UTC) FILETIME=[B462FDB0:01C99DA9] Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:48:33 -0000 Folks, Due to some "glitches" Ross was not able to post the following to the IDR mailing list, so I am re-posting it on his behalf. Yakov. ------------------------------------------------------------------ From: Ross Callon To: , "Thomas Narten" CC: "David Ward" , "Ross Callon" Date: Tue, 3 Mar 2009 13:55:07 -0500 Subject: RE: [Idr] IPR related to the flow-spec I-D I am not on the IDR email list, but Dave Ward forwarded Thomas' email to me. The additional applications in the more recent Juniper disclosure are patents where the inventors have not been involved in the IDR working group, and are not authors of the flow spec document. Therefore the connection between the applications and the IDR document was not noticed until very recently (there is no requirement that all IETF participants pay attention to every document in every IETF working group just in case they happen to have IPR on it). In fact the disclosure was posted approximately one week after the connection was noticed. The text that you refer to talks about "contributors". It is my impression however that if someone notices IPR that applies to an IETF document then they are supposed to disclose it when the connection is discovered, even if neither the inventors nor the person noticing the connection are contributors to the document in question. Ross ------------------------------------------------------- From: Thomas Narten Date: March 2, 2009 11:40:24 AM CST To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] IPR related to the flow-spec I-D Yakov Rekhter writes: I'd like to explain a bit of the confusion surrounding the IPR disclosure issue. On 12/23/2008 Juniper disclosed IPR on the flow-spec draft (https://datatracker.ietf.org/ipr/1052/), but it contained an incorrect "terms" section. Actually, I believe there is slightly more to it than this. IIRC, the December disclosure only listed a single patent application. The revised one lists one patent (issued) plus 5 patent applications (no information available AFAICT). So the disclosure has been expanded to include significantly (?) more possible IPR compared with the original disclosure. Correct? That said, the revised terms are IMO an improvement. Thanks. The disclosure was removed at Juniper's request and resubmitted on 02/09/2009 with the proper "terms" section. Unfortunately, Juniper's legal team released a number of IPR disclosures on or about 12/23/2008 and had to remove and correct all of them so, the sudden flurry of activity may have been worrying to some. You may have seen many corrected IPR disclosures on the IETF's IPR webpage (https://datatracker.ietf.org/ipr/about/) and more are to come. Juniper intended no harm or malice by these actions and Juniper is working to make certain that disclosures are made in a more timely manner. Regardng timing. The flow-spec document lists 6 authors, four of them with Juniper affiliations. The flow spec document was originally submitted as draft-marques-idr-flow-spec-00.txt back in June, 2003. Two of the authors on that document listed Juniper affiliations at that time. It seems surprising that the IPR that Juniper has just disclosed was only "recently" filed. If so, it is likely that there is significant prior art (since the document has been published and under discussion for so long). On the other hand, if the IPR was filed quite some time ago (i.e., when the work started), it raises the question of whether one of the IETF's most basic IPR obligations as described in RFC 3979 has been followed: 6.1.1. A Contributor's IPR in his or her Contribution Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 6.6 which the Contributor believes Covers or may ultimately Cover his or her Contribution, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6. ... 6.2.1. Timing of Disclosure Under Section 6.1.1 The IPR disclosure required pursuant to section 6.1.1 must be made as soon as reasonably possible after the Contribution is published in an Internet Draft unless the required disclosure is already on file. ... If a Contributor first learns of IPR in its Contribution that meets the conditions of Section 6.6, for example a new patent application or the discovery of a relevant patent in a patent portfolio, after the Contribution is published in an Internet-Draft, a disclosure must be made as soon as reasonably possible after the IPR becomes reasonably and personally known to the Contributor. Can the Contributers to this document please clarify the history and their role in it better w.r.t the IPR disclosures? I'm particularly concerned about the timing of the filing of the IPR and its subsequent disclosure. It seems rather odd that an ID that has been under discussion within the IETF for some 5 1/2 years would be subject of an IPR disclosure at such a late date (only after IETF LC starts) in the process. For example, do any of the patent applications list any of the document authors as inventors (and if so when was the application filed)? Or is this a case where the IETF contributers weren't involved in the patent application and wouldn't "reasonably" have been expected to known about it, i.e., as covered by the following in 3979: l. "Reasonably and personally known": means something an individual knows personally or, because of the job the individual holds, would reasonably be expected to know. This wording is used to indicate that an organization cannot purposely keep an individual in the dark about patents or patent applications just to avoid the disclosure requirement. But this requirement should not be interpreted as requiring the IETF Contributor or participant (or his or her represented organization, if any) to perform a patent search to find applicable IPR. It would be most helpful if all the contributers associated with the patent applications clarified their role to the WG, as was recently done in the case of draft-ietf-tcpm-tcp-auth-opt-03 in the TCPM WG. TCPM is also grappling with a disclosure made late in the process and the patent author in that case graciously published the patent application to help the WG in its deliberations on how to proceed. Thomas From john@jlc.net Thu Mar 5 08:26:17 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C74003A6A62 for ; Thu, 5 Mar 2009 08:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.187 X-Spam-Level: X-Spam-Status: No, score=-5.187 tagged_above=-999 required=5 tests=[AWL=1.412, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB1XpY6wqurA for ; Thu, 5 Mar 2009 08:26:17 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id D68A03A6A3F for ; Thu, 5 Mar 2009 08:26:16 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 92A9733C2E; Thu, 5 Mar 2009 11:26:46 -0500 (EST) Date: Thu, 5 Mar 2009 11:26:46 -0500 From: John Leslie To: idr@ietf.org, rcallon@juniper.net Message-ID: <20090305162646.GB65762@verdi> References: <200903051547.n25FlZM96518@magenta.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903051547.n25FlZM96518@magenta.juniper.net> User-Agent: Mutt/1.4.1i Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:26:17 -0000 > From: Ross Callon >> From: Thomas Narten >> >> IIRC, the December disclosure only listed a single patent application. >> The revised one lists one patent (issued) plus 5 patent applications >> (no information available AFAICT). So the disclosure has been expanded to >> include significantly (?) more possible IPR compared with the original >> disclosure. (It is a significant annoyance to those of us without "free" access to patent applications not published by the US patent office to be left guessing what IPR claims may be being disclosed.) > The additional applications in the more recent Juniper disclosure are > patents where the inventors have not been involved in the IDR working > group, and are not authors of the flow spec document. I am certainly happy to take Ross's word for this -- but additional possible (unknown) IPR claims still leave me wondering... > Therefore the connection between the applications and the IDR document > was not noticed until very recently (there is no requirement that all > IETF participants pay attention to every document in every IETF working > group just in case they happen to have IPR on it). Indeed -- I hope nobody is asking to add such a requirement. > The text that you refer to talks about "contributors". It is my > impression however that if someone notices IPR that applies to an IETF > document then they are supposed to disclose it when the connection is > discovered, even if neither the inventors nor the person noticing the > connection are contributors to the document in question. That is the way I read it, also. As far as the additional patent applications being listed, I fear we have to accept this: the requirement of "contributors" to disclose IPR claims they become aware of is unambiguous, while their ability to disclose the particulars of those claims is often severely limited by company policy. In this particular case, we're faced with a late disclosure (the December one, not the revision), and serious reason to believe that a "contributor" was aware of IPR claims but trusted Juniper lawyers to handle the disclosure. Lawyers habitually put things off as long as possible; and that's the behavior we'd like to change. We have two "sticks" we might apply: 1) asking for actual "royalty-free" terms, not Mutually-Assured- Destruction terms, based upon either the late filing or the vagueness of the claims disclosed; 2) refusing to proceed until the actual claims in all disclosed patent applications are available to all WG participants. Under the circumstances, I think either of these would be reasonable; though I could probably live with an assurance that the Juniper lawyers are willing to change their ways and that Juniper "contributors" will not in the future tolerate lenghty delays by Juniper lawyers. -- John Leslie From yakov@juniper.net Thu Mar 5 09:04:25 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B86E28C104 for ; Thu, 5 Mar 2009 09:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1jI3KONOInX for ; Thu, 5 Mar 2009 09:04:24 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 724DE28C3CB for ; Thu, 5 Mar 2009 09:04:23 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSbAGNJ0xyjucg3CuN5JQ1LgDZmb7W+Ru@postini.com; Thu, 05 Mar 2009 09:04:53 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 5 Mar 2009 09:04:07 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 09:04:07 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 09:04:07 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 09:04:06 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n25H46M31971; Thu, 5 Mar 2009 09:04:06 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200903051704.n25H46M31971@magenta.juniper.net> To: David Ward In-Reply-To: <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> X-MH-In-Reply-To: David Ward message dated "Wed, 04 Mar 2009 16:40:38 -0600." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <42519.1236272646.1@juniper.net> Date: Thu, 5 Mar 2009 09:04:06 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 05 Mar 2009 17:04:06.0592 (UTC) FILETIME=[64B35C00:01C99DB4] Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:04:25 -0000 Dave, > Sue, Yakov - > > This deadline has come and gone with zero comments on the re-LC of > this draft. Given the comments and discussion on IPR disclosures on > the IDR list in general, I (and the IESG) need a more concrete sign > that the WG has consensus that the document should continue to > progress towards publication. Agreed. With this in mind I'd like to ask members of the WG to reply to this e-mail with either "yes" or "no" (where "yes" means progress draft-ietf-idr-flow-spec towards standardization, and "no" means do not progress draft-ietf-idr-flow-spec towards standardization). Please note that (a) silence does not count either way, and (b) a handful of "yes" or "no" does not make consensus either way. The deadline for response is March 19, 2009. Yakov. > ------------ > Related to IPR, I strongly encourage all IETF participants to read and > understand: > > http://www.ietf.org/overview.html (read and understand the NOTE > WELL) > > http://www.ietf.org/rfc/rfc3979.txt?number=3979 > > http://www.ietf.org/rfc/rfc4879.txt > > > I refer the WG to these documents and pointers as well: > > http://www.ietf.org/rfc/rfc3669.txt?number=3669 > > https://datatracker.ietf.org/ipr/ > > http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF72/72newcomer s.ppt > (page 48 - 56) > > Newcomer's training at the upcoming IETF held by the edu team > on Sunday 2009.03.22 at 1300 in Imperial B (see https://datatracker.ietf.org/ meeting/74/agenda.txt > for any changes) > > > > If you have difficulty keeping up with IPR disclosures, here is an RSS > feed of all IETF IPR disclosures: > > feed:https://datatracker.ietf.org/feed/ipr/ > > If you believe that you'd like the ADs to spend some time in the > RTGAREA WG meeting to provide some education on IPR issues, rule, > requirements, etc at the IETF please contact us privately or mailto:rtg-ads@t ools.ietf.org > > Thanks and hope it helps. > > -DWard > > On Feb 17, 2009, at 6:30 PM, Yakov Rekhter wrote: > > > Folks, > > > > Given the recent IPR disclosure (https://datatracker.ietf.org/ipr/ > > 1088) > > associated with the flow-spec draft > > (http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-05.txt ) > > we are going to re-WG-LC the document and rerun the publication > > process. > > > > The deadline for comments is 3/2/2009. > > > > Sue & Yakov. > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > From cayle.spandon@gmail.com Thu Mar 5 09:35:26 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACEA63A6879 for ; Thu, 5 Mar 2009 09:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVHwM4MMq7W0 for ; Thu, 5 Mar 2009 09:35:26 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id D3EA728C1DE for ; Thu, 5 Mar 2009 09:35:23 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so24489yxm.49 for ; Thu, 05 Mar 2009 09:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=9zvBDPi4VuZveI4VURj84ue6sOyRuEg51TNfmi+5atI=; b=VAJjtvG2bH3bFz/NHt93jfUdlu7yf+RFOwCA094+f0HyCrW1UV5QsL8jfGVCEci7TE cTz9evNKFeKD955QsNHxuIv5HpCWarZ525kjrGcjFehGEhVR9l+LzUG726WXRjWHJn11 mIRnbFwB5LQk5FlYv2EyGxCCsuu/1sgLo0eNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=VESPLfKZgwb/wzkpkaeJU3DCGr7IritiC2V6gv53EJn4EevYrJRHCZFSygQKnEyHdL rxcwHK8HFzmTEJWxag4nJnr25I1Wiazj4u+fbhLqfsxsgwzPCeQKxm3j0DyGipxInR2M HJd+ACTHcxYgJoOZr/xi4DcmZfk0Yd9EZJDlI= MIME-Version: 1.0 Received: by 10.142.173.20 with SMTP id v20mr235932wfe.276.1236274552793; Thu, 05 Mar 2009 09:35:52 -0800 (PST) In-Reply-To: <200903051704.n25H46M31971@magenta.juniper.net> References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> Date: Thu, 5 Mar 2009 12:35:52 -0500 Message-ID: <71c13900903050935h6820bf45k9684a47dd28c1688@mail.gmail.com> From: Cayle Spandon To: Yakov Rekhter , idr Content-Type: multipart/alternative; boundary=000e0cd2bfca906bc2046462997b Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:35:26 -0000 --000e0cd2bfca906bc2046462997b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > With this in mind I'd like to ask members of the WG to reply to > this e-mail with either "yes" or "no" (where "yes" means progress > draft-ietf-idr-flow-spec towards standardization, and "no" means > do not progress draft-ietf-idr-flow-spec towards standardization). > yes --000e0cd2bfca906bc2046462997b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
With this in mind I'd like to ask members of the WG to reply to
this e-mail with either "yes" or "no" (where "yes" means progress
draft-ietf-idr-flow-spec towards standardization, and "no" means
do not progress draft-ietf-idr-flow-spec towards standardization).

yes
--000e0cd2bfca906bc2046462997b-- From rahul@juniper.net Thu Mar 5 11:00:50 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6557128C1A3 for ; Thu, 5 Mar 2009 11:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMjEV-UwrXDw for ; Thu, 5 Mar 2009 11:00:49 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 533B828C394 for ; Thu, 5 Mar 2009 11:00:49 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSbAhfgK/0ALt4hH8+zCA79sFORiXy1EY@postini.com; Thu, 05 Mar 2009 11:01:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 5 Mar 2009 11:00:00 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 11:00:01 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 11:00:00 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 10:59:59 -0800 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n25IxxM89927; Thu, 5 Mar 2009 10:59:59 -0800 (PST) (envelope-from rahul@juniper.net) Date: Thu, 5 Mar 2009 10:59:59 -0800 From: Rahul Aggarwal To: Yakov Rekhter In-Reply-To: <200903051704.n25H46M31971@magenta.juniper.net> Message-ID: <20090305105942.O15508@sapphire.juniper.net> References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-OriginalArrivalTime: 05 Mar 2009 18:59:59.0774 (UTC) FILETIME=[951EBBE0:01C99DC4] Cc: idr@ietf.org, David Ward Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 19:00:50 -0000 Hi Yakov, Yes. rahul On Thu, 5 Mar 2009, Yakov Rekhter wrote: > Dave, > > > Sue, Yakov - > > > > This deadline has come and gone with zero comments on the re-LC of > > this draft. Given the comments and discussion on IPR disclosures on > > the IDR list in general, I (and the IESG) need a more concrete sign > > that the WG has consensus that the document should continue to > > progress towards publication. > > Agreed. > > With this in mind I'd like to ask members of the WG to reply to > this e-mail with either "yes" or "no" (where "yes" means progress > draft-ietf-idr-flow-spec towards standardization, and "no" means > do not progress draft-ietf-idr-flow-spec towards standardization). > > Please note that (a) silence does not count either way, and (b) a > handful of "yes" or "no" does not make consensus either way. > > The deadline for response is March 19, 2009. > > Yakov. > > > ------------ > > > Related to IPR, I strongly encourage all IETF participants to read and > > understand: > > > > http://www.ietf.org/overview.html (read and understand the NOTE > > WELL) > > > > http://www.ietf.org/rfc/rfc3979.txt?number=3979 > > > > http://www.ietf.org/rfc/rfc4879.txt > > > > > > I refer the WG to these documents and pointers as well: > > > > http://www.ietf.org/rfc/rfc3669.txt?number=3669 > > > > https://datatracker.ietf.org/ipr/ > > > > http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF72/72newcomer > s.ppt > > (page 48 - 56) > > > > Newcomer's training at the upcoming IETF held by the edu team > > on Sunday 2009.03.22 at 1300 in Imperial B (see https://datatracker.ietf.org/ > meeting/74/agenda.txt > > for any changes) > > > > > > > > If you have difficulty keeping up with IPR disclosures, here is an RSS > > feed of all IETF IPR disclosures: > > > > feed:https://datatracker.ietf.org/feed/ipr/ > > > > If you believe that you'd like the ADs to spend some time in the > > RTGAREA WG meeting to provide some education on IPR issues, rule, > > requirements, etc at the IETF please contact us privately or mailto:rtg-ads@t > ools.ietf.org > > > > Thanks and hope it helps. > > > > -DWard > > > > On Feb 17, 2009, at 6:30 PM, Yakov Rekhter wrote: > > > > > Folks, > > > > > > Given the recent IPR disclosure (https://datatracker.ietf.org/ipr/ > > > 1088) > > > associated with the flow-spec draft > > > (http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-05.txt ) > > > we are going to re-WG-LC the document and rerun the publication > > > process. > > > > > > The deadline for comments is 3/2/2009. > > > > > > Sue & Yakov. > > > _______________________________________________ > > > 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 robert@raszuk.net Thu Mar 5 12:35:39 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB943A6BB8 for ; Thu, 5 Mar 2009 12:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhbLLOVZxzBO for ; Thu, 5 Mar 2009 12:35:38 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 44B4D3A6A84 for ; Thu, 5 Mar 2009 12:35:38 -0800 (PST) Received: (qmail 20450 invoked by uid 399); 5 Mar 2009 20:36:07 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.28.42) by mail37.opentransfer.com with SMTP; 5 Mar 2009 20:36:07 -0000 Message-ID: <49B037B5.2070807@raszuk.net> Date: Thu, 05 Mar 2009 12:36:05 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Yakov Rekhter References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> In-Reply-To: <200903051704.n25H46M31971@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 20:35:39 -0000 Hi Yakov, Since the only reason for WG last re-call was the IPR disclosure and since other WG members already voiced the concern regarding current royalty-bearing license wouldn't it be much more effective to hold this WG last call till the IPR rights are sorted out ? By sorted out I would consider either of the below: * A statement from the author of the last disclosure to this WG that the disclosure https://datatracker.ietf.org/ipr/1106/ is a final one. * A new disclosure resubmission with clear royalty-free license of right. Many thx, R. > Dave, > >> Sue, Yakov - >> >> This deadline has come and gone with zero comments on the re-LC of >> this draft. Given the comments and discussion on IPR disclosures on >> the IDR list in general, I (and the IESG) need a more concrete sign >> that the WG has consensus that the document should continue to >> progress towards publication. > > Agreed. > > With this in mind I'd like to ask members of the WG to reply to > this e-mail with either "yes" or "no" (where "yes" means progress > draft-ietf-idr-flow-spec towards standardization, and "no" means > do not progress draft-ietf-idr-flow-spec towards standardization). > > Please note that (a) silence does not count either way, and (b) a > handful of "yes" or "no" does not make consensus either way. > > The deadline for response is March 19, 2009. > > Yakov. From rcallon@juniper.net Thu Mar 5 14:56:05 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98ACF3A6988 for ; Thu, 5 Mar 2009 14:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34utqijQjny7 for ; Thu, 5 Mar 2009 14:56:04 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id D245F3A67B1 for ; Thu, 5 Mar 2009 14:56:04 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSbBYoPKiPVkfpWpe+TvpTvjjyK55Pn6K@postini.com; Thu, 05 Mar 2009 14:56:35 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 5 Mar 2009 14:55:37 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 14:55:37 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 14:55:37 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 17:55:31 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05D45391@emailwf1.jnpr.net> In-Reply-To: <20090305162646.GB65762@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] IPR related to the flow-spec I-D Thread-Index: AcmdrzCMyFigVr5xTJCGBsx8DuDT5QADguFA References: <200903051547.n25FlZM96518@magenta.juniper.net> <20090305162646.GB65762@verdi> From: Ross Callon To: "John Leslie" , X-OriginalArrivalTime: 05 Mar 2009 22:55:37.0320 (UTC) FILETIME=[7FC10E80:01C99DE5] Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 22:56:05 -0000 > ... Under the circumstances, I think either of these would be=20 > reasonable; though I could probably live with an assurance that > the Juniper lawyers are willing to change their ways and that > Juniper "contributors" will not in the future tolerate lengthy > delays by Juniper lawyers. > > John Leslie Ron Bonica, Tom Walsh and I have most certainly "educated" our lawyers in very strong terms. Tom is also working to make sure that Juniper employees involved in the IETF are reminded that they can't tolerate long delays by the lawyers and have an individual responsibility to make sure that any IPR that they know about is disclosed in a timely fashion. In addition, the IESG is planning on stating the same thing publicly (for all contributors from any company), both via email (as soon as we can agree on precisely what to say) and quite likely at the plenary in San Francisco. Also, I will make a very short statement at the routing area open meeting reminding people that they have an individual responsibility to disclose IPR in a timely fashion (a small single digit number of weeks, definitely not years).=20 Ross=20 =20 From tony.li@tony.li Thu Mar 5 19:22:01 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FBBD3A6BE0 for ; Thu, 5 Mar 2009 19:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbfY0T8xR-W0 for ; Thu, 5 Mar 2009 19:22:00 -0800 (PST) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id A48CB3A6BBD for ; Thu, 5 Mar 2009 19:22:00 -0800 (PST) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id PQT41b0070S2fkCA8fNXdp; Fri, 06 Mar 2009 03:22:31 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id PfNV1b00b3L8a8Q8VfNXfT; Fri, 06 Mar 2009 03:22:31 +0000 Message-ID: <49B096EE.7050303@tony.li> Date: Thu, 05 Mar 2009 19:22:22 -0800 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Yakov Rekhter References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> In-Reply-To: <200903051704.n25H46M31971@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, David Ward Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 03:22:01 -0000 Yakov Rekhter wrote: > With this in mind I'd like to ask members of the WG to reply to > this e-mail with either "yes" or "no" (where "yes" means progress > draft-ietf-idr-flow-spec towards standardization, and "no" means > do not progress draft-ietf-idr-flow-spec towards standardization). No thank you. Tony From jgs@juniper.net Fri Mar 6 00:55:00 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A903A687C for ; Fri, 6 Mar 2009 00:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFXwU2eaCLiD for ; Fri, 6 Mar 2009 00:54:59 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 12E433A659B for ; Fri, 6 Mar 2009 00:54:59 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSbDk7YbhUeonrNxGxGlmDN6UlE/v+Fs7@postini.com; Fri, 06 Mar 2009 00:55:29 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 6 Mar 2009 00:52:23 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 00:52:23 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 00:52:23 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Mar 2009 00:52:22 -0800 Received: from sa-nc-ipg-29.static.jnpr.net ([172.23.0.29]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n268qKM63315; Fri, 6 Mar 2009 00:52:21 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: From: "John G. Scudder" To: Yakov Rekhter In-Reply-To: <200903051704.n25H46M31971@magenta.juniper.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 10:52:19 +0200 References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Mar 2009 08:52:22.0733 (UTC) FILETIME=[DD717FD0:01C99E38] Cc: idr@ietf.org, David Ward Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 08:55:00 -0000 Yakov, I've held back from replying until now because of my job affiliation, but since you ask: Yes. I'd like to think that I would have said the same regardless of affiliation though it's hard to prove a hypothetical. FWIW I've read the current arguments related to IPR issues. My *personal* feeling about this is that I think the current situation with IPR is pretty awful, but that problem and its remedies are both far beyond the scope of what the IETF is competent and able to accomplish. Although the IETF is famous for trying to boil the ocean, it would be great to skip that step this time. IMO the (corrected) licensing terms that were disclosed are nearly the least repulsive possible, and probably the least repulsive that it's reasonable to expect. Making the best of a bad situation, --John On Mar 5, 2009, at 7:04 PM, Yakov Rekhter wrote: > Dave, > >> Sue, Yakov - >> >> This deadline has come and gone with zero comments on the re-LC of >> this draft. Given the comments and discussion on IPR disclosures on >> the IDR list in general, I (and the IESG) need a more concrete sign >> that the WG has consensus that the document should continue to >> progress towards publication. > > Agreed. > > With this in mind I'd like to ask members of the WG to reply to > this e-mail with either "yes" or "no" (where "yes" means progress > draft-ietf-idr-flow-spec towards standardization, and "no" means > do not progress draft-ietf-idr-flow-spec towards standardization). > > Please note that (a) silence does not count either way, and (b) a > handful of "yes" or "no" does not make consensus either way. > > The deadline for response is March 19, 2009. > > Yakov. > >> ------------ > >> Related to IPR, I strongly encourage all IETF participants to read >> and >> understand: >> >> http://www.ietf.org/overview.html (read and understand the NOTE >> WELL) >> >> http://www.ietf.org/rfc/rfc3979.txt?number=3979 >> >> http://www.ietf.org/rfc/rfc4879.txt >> >> >> I refer the WG to these documents and pointers as well: >> >> http://www.ietf.org/rfc/rfc3669.txt?number=3669 >> >> https://datatracker.ietf.org/ipr/ >> >> http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF72/72newcomer > s.ppt >> (page 48 - 56) >> >> Newcomer's training at the upcoming IETF held by the edu team >> on Sunday 2009.03.22 at 1300 in Imperial B (see https://datatracker.ietf.org/ > meeting/74/agenda.txt >> for any changes) >> >> >> >> If you have difficulty keeping up with IPR disclosures, here is an >> RSS >> feed of all IETF IPR disclosures: >> >> feed:https://datatracker.ietf.org/feed/ipr/ >> >> If you believe that you'd like the ADs to spend some time in the >> RTGAREA WG meeting to provide some education on IPR issues, rule, >> requirements, etc at the IETF please contact us privately or mailto:rtg-ads@t > ools.ietf.org >> >> Thanks and hope it helps. >> >> -DWard >> >> On Feb 17, 2009, at 6:30 PM, Yakov Rekhter wrote: >> >>> Folks, >>> >>> Given the recent IPR disclosure (https://datatracker.ietf.org/ipr/ >>> 1088) >>> associated with the flow-spec draft >>> (http://www.ietf.org/internet-drafts/draft-ietf-idr-flow- >>> spec-05.txt ) >>> we are going to re-WG-LC the document and rerun the publication >>> process. >>> >>> The deadline for comments is 3/2/2009. >>> >>> Sue & Yakov. >>> _______________________________________________ >>> 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 robert@raszuk.net Fri Mar 6 01:06:14 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991893A69C7 for ; Fri, 6 Mar 2009 01:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXbPR2SXP6xg for ; Fri, 6 Mar 2009 01:06:13 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 9EA863A6977 for ; Fri, 6 Mar 2009 01:06:13 -0800 (PST) Received: (qmail 863 invoked by uid 399); 6 Mar 2009 09:06:43 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.23.163) by mail37.opentransfer.com with SMTP; 6 Mar 2009 09:06:43 -0000 Message-ID: <49B0E79F.6030506@raszuk.net> Date: Fri, 06 Mar 2009 01:06:39 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "John G. Scudder" References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 09:06:14 -0000 Hi John, > IMO the (corrected) licensing terms that were disclosed are nearly the > least repulsive possible, and probably the least repulsive that it's > reasonable to expect. Just FYI I examined few other IPR disclosures and apparently there are many more offering royality-free licences yet containing protection against patent litigations. They apparently can go together just fine. Example: Subject to the terms and conditions of this License, Google hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this License) patent license for patents necessarily infringed by implementation (in whole or in part) of this specification. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the implementation of the specification constitutes direct or contributory patent infringement, then any patent licenses for the specification granted to You under this License shall terminate as of the date such litigation is filed. Btw: Results 1-10 of about 2,150 for "royalty-free" AND IPR. (0.14 seconds) Results 1-10 of about 198 for "royalty-bearing" AND IPR. (0.24 seconds) SRC: http://www.googlesyndicatedsearch.com/u/ietf The query results are self explanatory :). Cheers, R. From jgs@juniper.net Fri Mar 6 01:41:10 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7843A6B36 for ; Fri, 6 Mar 2009 01:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9PFVMXrW9DK for ; Fri, 6 Mar 2009 01:41:09 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 6DB1B3A67EA for ; Fri, 6 Mar 2009 01:41:09 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSbDv0eCa7WrDMBdHGu+xnRuh2vBJ3NJI@postini.com; Fri, 06 Mar 2009 01:41:40 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 6 Mar 2009 01:39:32 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 01:39:32 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 01:39:32 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Mar 2009 01:39:32 -0800 Received: from sa-nc-ipg-29.static.jnpr.net ([172.23.0.29]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n269dTM84059; Fri, 6 Mar 2009 01:39:30 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: <3322C991-4504-477D-AB50-4D709154747F@juniper.net> From: "John G. Scudder" To: robert@raszuk.net In-Reply-To: <49B0E79F.6030506@raszuk.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 11:39:27 +0200 References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> <49B0E79F.6030506@raszuk.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Mar 2009 09:39:32.0067 (UTC) FILETIME=[73DB9B30:01C99E3F] Cc: Yakov Rekhter , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 09:41:11 -0000 Robert, Summary, I think you're not correct in characterizing the current disclosure as "royalty-bearing". I don't see how the license you quoted is very different from the one published with the recent (corrected) IPR disclosure (http://www.ietf.org/ietf/IPR/juniper-ipr-draft-ietf-idr-flow-spec-03.txt ): "If this standard is adopted, Juniper will not assert any patents owned or controlled by Juniper against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Juniper retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Juniper or any of Juniper's affiliates or successors in title or against any products of Juniper or any products of any of Juniper's affiliates either alone or in combination with other products; and Juniper retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard." There are some differences between this and the license you quote, and I'm not a lawyer so prefer to avoid a detailed analysis of those differences, but to a first approximation the above paragraph is the same as what you mention: a royality-free licence containing protection against patent litigation. The following paragraph does mention royalties: "Royalty-bearing licenses will be available to anyone who prefers that option." but it's only provided as an option for those who don't choose the mutually assured destruction version provided by the first paragraph. This is an *expansion* of the options available, not a reduction. The license you quote below is substantially the same as the first paragraph quoted above, but omits the expansion of options provided by the second paragraph quoted above. (I don't think this makes any real difference; the patent holder can choose to offer a royalty-bearing license whether or not that is explicitly stated in the IPR disclosure.) I would have thought this to be obvious, but the mere presence of the string "royalty-bearing" in the IPR statement is absolutely not a reason to characterize the overall terms as royalty-bearing rather than royalty-free. For this reason, I think the search results you cite, far from being "self explanatory", are basically meaningless. Perhaps it was a marketing error not to use the string "royalty-free" in the IPR statement. --John On Mar 6, 2009, at 11:06 AM, Robert Raszuk wrote: > Hi John, > >> IMO the (corrected) licensing terms that were disclosed are nearly >> the least repulsive possible, and probably the least repulsive that >> it's reasonable to expect. > > Just FYI I examined few other IPR disclosures and apparently there > are many more offering royality-free licences yet containing > protection against patent litigations. They apparently can go > together just fine. > > Example: > > Subject to the terms and conditions of this License, Google hereby > grants to You a perpetual, worldwide, non-exclusive, no-charge, > royalty-free, irrevocable (except as stated in this License) patent > license for patents necessarily infringed by implementation (in > whole or in part) of this specification. If You institute patent > litigation against any entity (including a cross-claim or > counterclaim in a lawsuit) alleging that the implementation of the > specification constitutes direct or contributory patent > infringement, then any patent licenses for the specification granted > to You under this License shall terminate as of the date such > litigation is filed. > > Btw: > > Results 1-10 of about 2,150 for "royalty-free" AND IPR. (0.14 seconds) > Results 1-10 of about 198 for "royalty-bearing" AND IPR. (0.24 > seconds) > > SRC: http://www.googlesyndicatedsearch.com/u/ietf > The query results are self explanatory :). > > Cheers, > R. > From jgs@juniper.net Fri Mar 6 01:41:51 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E6B3A6BDA for ; Fri, 6 Mar 2009 01:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4ZkNGWfshY2 for ; Fri, 6 Mar 2009 01:41:51 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id A1AEC3A689C for ; Fri, 6 Mar 2009 01:41:50 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSbDv/CkQGygVYBb8cL0Tqu7nbZ9Vt6gn@postini.com; Fri, 06 Mar 2009 01:42:21 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 6 Mar 2009 01:40:33 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 01:40:33 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 01:40:33 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Mar 2009 01:40:32 -0800 Received: from sa-nc-ipg-29.static.jnpr.net ([172.23.0.29]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n269eUM84623; Fri, 6 Mar 2009 01:40:30 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: From: "John G. Scudder" To: robert@raszuk.net In-Reply-To: <49AF0F2E.70307@raszuk.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 11:40:29 +0200 References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <49AF086C.5060601@tony.li> <49AF0F2E.70307@raszuk.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Mar 2009 09:40:32.0504 (UTC) FILETIME=[97E18F80:01C99E3F] Cc: Yakov Rekhter , Tony Li , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 09:41:51 -0000 Robert, On Mar 5, 2009, at 1:30 AM, Robert Raszuk wrote: > There seems to six basic types of licensing: ... > The draft in question is disclosed as "royalty-bearing license of > right". Is this your own legal interpretation or is there some document which specifically says "royalty-bearing license of right" about this particular draft? If so, a citation would help. --John From robert@raszuk.net Fri Mar 6 03:23:05 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28D03A693F for ; Fri, 6 Mar 2009 03:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIz0nuL0TAVD for ; Fri, 6 Mar 2009 03:23:05 -0800 (PST) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 218BB3A6C48 for ; Fri, 6 Mar 2009 03:23:02 -0800 (PST) Received: (qmail 27427 invoked by uid 399); 6 Mar 2009 11:23:32 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.240.147) by mail37.opentransfer.com with SMTP; 6 Mar 2009 11:23:32 -0000 Message-ID: <49B107AE.2050100@raszuk.net> Date: Fri, 06 Mar 2009 03:23:26 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "John G. Scudder" References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> <49B0E79F.6030506@raszuk.net> <3322C991-4504-477D-AB50-4D709154747F@juniper.net> In-Reply-To: <3322C991-4504-477D-AB50-4D709154747F@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 11:23:05 -0000 Hi John, > Perhaps it was a marketing error not to use the string "royalty-free" in > the IPR statement. Can this supposedly a "marketing error" just be corrected by resubmission of a new disclosure and we can finish this so non technical thread soon ? Cheers, R. From john@jlc.net Fri Mar 6 06:51:58 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FEE43A6CA0 for ; Fri, 6 Mar 2009 06:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.903 X-Spam-Level: X-Spam-Status: No, score=-4.903 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MONEYTERMS=0.681] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI6Z38yPFrV8 for ; Fri, 6 Mar 2009 06:51:57 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 019273A680B for ; Fri, 6 Mar 2009 06:51:57 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id BDEFF33C2E; Fri, 6 Mar 2009 09:52:27 -0500 (EST) Date: Fri, 6 Mar 2009 09:52:27 -0500 From: John Leslie To: "John G. Scudder" , idr@ietf.org Message-ID: <20090306145227.GA54798@verdi> References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> <49B0E79F.6030506@raszuk.net> <3322C991-4504-477D-AB50-4D709154747F@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3322C991-4504-477D-AB50-4D709154747F@juniper.net> User-Agent: Mutt/1.4.1i Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 14:51:58 -0000 IANAL, but John G. Scudder wrote: > > I don't see how the license you quoted is very different from the one > published with the recent (corrected) IPR disclosure > (http://www.ietf.org/ietf/IPR/juniper-ipr-draft-ietf-idr-flow-spec-03.txt ): > > "If this standard is adopted, Juniper will not assert any patents > owned or controlled by Juniper against any party for making, using, > selling, importing or offering for sale a product that implements the > standard, provided, however that Juniper retains the right to assert > its patents (including the right to claim past royalties) against any > party that asserts a patent it owns or controls (either directly or > indirectly) against Juniper or any of Juniper's affiliates or > successors in title or against any products of Juniper or any products > of any of Juniper's affiliates either alone or in combination with > other products; and Juniper retains the right to assert its patents > against any product or portion thereof that is not necessary for > compliance with the standard." > > There are some differences between this and the license you quote, and > I'm not a lawyer so prefer to avoid a detailed analysis of those > differences, but to a first approximation the above paragraph is the > same as what you mention: a royality-free licence containing > protection against patent litigation. I see nothing in there that looks like a license: it is rather a promise not to sue under certain conditions. While the Google version clearly grants a license, albeit revokable: " " Subject to the terms and conditions of this License, Google hereby " grants to You a perpetual, worldwide, non-exclusive, no-charge, " royalty-free, irrevocable (except as stated in this License) patent " license for patents necessarily infringed by implementation (in whole or " in part) of this specification. If You institute patent litigation " against any entity (including a cross-claim or counterclaim in a " lawsuit) alleging that the implementation of the specification " constitutes direct or contributory patent infringement, then any patent " licenses for the specification granted to You under this License shall " terminate as of the date such litigation is filed. The differences are rather substantial: - Google will not seek royalties predating the date of filing; - Google grants the license whether or not a standard is adopted; - Google revokes only for a suit over _this_ specification; - Google doesn't reserve "not necessary for compliance". IMHO, while Juniper's current language may or may not be the best we can hope for, it simply isn't a royalty-free license. While I dislike playing lawyer games, I'm afraid we ignore these differences at significant peril. It's not that I expect Juniper managment to become unreasonable: I don't expect them to file litigation over this. It's what happens when companies enter bankruptcy: a whole new set of lawyers take over, interested _only_ in maximizing the value against which they can charge for what lawyers do -- and not the least bit interested in carrying on the original vision of the company's founders. In today's times, any company faces increased risk of bankruptcy. And it doesn't need to be Jupiter: any two-bit company can start the meltdown by filing patent-infringement litigation. Any other company can contribute to the meltdown by exercising the rights reserved in IPR claims like Jupiter's. So, while I'm not exactly _happy_ living in a world of Google IPR filings, I'm a whole lot happier with that than a world of Jupiter IPR filings. Bottom line: I'd like to give Jupiter more time to think it over, and not progress flow-spec to standard right yet. -- John Leslie From jgs@juniper.net Fri Mar 6 07:23:42 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD363A68C0 for ; Fri, 6 Mar 2009 07:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MONEYTERMS=0.681] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t133FKN3QKOt for ; Fri, 6 Mar 2009 07:23:41 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 4058E3A6CC0 for ; Fri, 6 Mar 2009 07:23:41 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSbFAGe6DabmST0bRRtUZ7PKMF9B7ISut@postini.com; Fri, 06 Mar 2009 07:24:12 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 6 Mar 2009 07:23:30 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 07:23:30 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 07:23:29 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 07:23:28 -0800 Received: from sa-nc-ipg-29.static.jnpr.net ([172.23.0.29]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n26FNQM49780; Fri, 6 Mar 2009 07:23:26 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: <498AA798-C6BD-4978-8E9C-A08B1AC7C346@juniper.net> From: "John G. Scudder" To: John Leslie In-Reply-To: <20090306145227.GA54798@verdi> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 17:23:23 +0200 References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> <49B0E79F.6030506@raszuk.net> <3322C991-4504-477D-AB50-4D709154747F@juniper.net> <20090306145227.GA54798@verdi> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Mar 2009 15:23:28.0958 (UTC) FILETIME=[806745E0:01C99E6F] Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:23:42 -0000 On Mar 6, 2009, at 4:52 PM, John Leslie wrote: > IANAL, but Nor am I of course, and in my experience the IETF is at its very worst when engineers try to play lawyer. Although I'm not a lawyer I have gotten opinions on a few things from counsel from time to time, one of which I'll relate below. > I see nothing in there that looks like a license: it is rather a > promise not to sue under certain conditions. Not being a lawyer I will not comment on the above other than to point out that you aren't either. If someone wants to make a decision based on allegations that the IPR disclosure language does or doesn't have certain consequences, or is or isn't a "license", IMO they would do well to do so based on a competent legal opinion. > IMHO, while Juniper's current language may or may not be the best > we can hope for, it simply isn't a royalty-free license. Same comment applies -- I respectfully don't wish to rely on your opinion on technical legal matters, of which this is one. > While I dislike playing lawyer games, In that case I suggest you get an opinion from a competent lawyer instead of, as you put it, playing lawyer games. > It's not that I expect Juniper managment to become unreasonable: > I don't expect them to file litigation over this. It's what happens > when companies enter bankruptcy: a whole new set of lawyers take > over, interested _only_ in maximizing the value against which they > can charge for what lawyers do -- and not the least bit interested > in carrying on the original vision of the company's founders. This is the part I actually got opinion from counsel over. Their opinion was that Juniper's public commitments to the IETF would continue to be binding on successors. Thus it is not a matter of simply having to trust in the good will of the (hypothetical) successor -- there's a binding, written legal commitment. Get your own legal opinion if it's sufficiently important to you, of course. > In today's times, any company faces increased risk of bankruptcy. > And it doesn't need to be Jupiter: any two-bit company can start > the meltdown by filing patent-infringement litigation. Any other > company can contribute to the meltdown by exercising the rights > reserved in IPR claims like Jupiter's. I think you meant Juniper, not Jupiter, but whoever you meant, what some hypothetical third party ("two-bit company") might or might not do seems irrelevant to the case under discussion. --John From rbonica@juniper.net Fri Mar 6 11:19:44 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6DEB3A6B37 for ; Fri, 6 Mar 2009 11:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ABrKQ3wHvbp for ; Fri, 6 Mar 2009 11:19:44 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 9FF3F3A6A07 for ; Fri, 6 Mar 2009 11:19:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSbF3bsY80jXTh+1cgd7vAIrGAiwg/hTZ@postini.com; Fri, 06 Mar 2009 11:20:15 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 6 Mar 2009 11:19:27 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 11:19:27 -0800 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 11:19:27 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 6 Mar 2009 14:19:25 -0500 Received: from [172.28.134.5] ([172.28.134.5] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Mar 2009 14:19:25 -0500 Message-ID: <49B17738.2070905@juniper.net> Date: Fri, 6 Mar 2009 14:19:20 -0500 From: Ron Bonica User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "John G. Scudder" References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2009 19:19:25.0398 (UTC) FILETIME=[764C9760:01C99E90] Cc: Yakov Rekhter , David Ward , idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 19:19:44 -0000 +1 John G. Scudder wrote: > Yakov, > > I've held back from replying until now because of my job affiliation, > but since you ask: > > Yes. > > I'd like to think that I would have said the same regardless of > affiliation though it's hard to prove a hypothetical. > > FWIW I've read the current arguments related to IPR issues. My > *personal* feeling about this is that I think the current situation with > IPR is pretty awful, but that problem and its remedies are both far > beyond the scope of what the IETF is competent and able to accomplish. > Although the IETF is famous for trying to boil the ocean, it would be > great to skip that step this time. > > IMO the (corrected) licensing terms that were disclosed are nearly the > least repulsive possible, and probably the least repulsive that it's > reasonable to expect. > > Making the best of a bad situation, > > --John > > On Mar 5, 2009, at 7:04 PM, Yakov Rekhter wrote: > >> Dave, >> >>> Sue, Yakov - >>> >>> This deadline has come and gone with zero comments on the re-LC of >>> this draft. Given the comments and discussion on IPR disclosures on >>> the IDR list in general, I (and the IESG) need a more concrete sign >>> that the WG has consensus that the document should continue to >>> progress towards publication. >> >> Agreed. >> >> With this in mind I'd like to ask members of the WG to reply to >> this e-mail with either "yes" or "no" (where "yes" means progress >> draft-ietf-idr-flow-spec towards standardization, and "no" means >> do not progress draft-ietf-idr-flow-spec towards standardization). >> >> Please note that (a) silence does not count either way, and (b) a >> handful of "yes" or "no" does not make consensus either way. >> >> The deadline for response is March 19, 2009. >> >> Yakov. >> >>> ------------ >> >>> Related to IPR, I strongly encourage all IETF participants to read and >>> understand: >>> >>> http://www.ietf.org/overview.html (read and understand the NOTE >>> WELL) >>> >>> http://www.ietf.org/rfc/rfc3979.txt?number=3979 >>> >>> http://www.ietf.org/rfc/rfc4879.txt >>> >>> >>> I refer the WG to these documents and pointers as well: >>> >>> http://www.ietf.org/rfc/rfc3669.txt?number=3669 >>> >>> https://datatracker.ietf.org/ipr/ >>> >>> >>> http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF72/72newcomer >> s.ppt >>> (page 48 - 56) >>> >>> Newcomer's training at the upcoming IETF held by the edu team >>> on Sunday 2009.03.22 at 1300 in Imperial B (see >>> https://datatracker.ietf.org/ >> meeting/74/agenda.txt >>> for any changes) >>> >>> >>> >>> If you have difficulty keeping up with IPR disclosures, here is an RSS >>> feed of all IETF IPR disclosures: >>> >>> feed:https://datatracker.ietf.org/feed/ipr/ >>> >>> If you believe that you'd like the ADs to spend some time in the >>> RTGAREA WG meeting to provide some education on IPR issues, rule, >>> requirements, etc at the IETF please contact us privately or >>> mailto:rtg-ads@t >> ools.ietf.org >>> >>> Thanks and hope it helps. >>> >>> -DWard >>> >>> On Feb 17, 2009, at 6:30 PM, Yakov Rekhter wrote: >>> >>>> Folks, >>>> >>>> Given the recent IPR disclosure (https://datatracker.ietf.org/ipr/ >>>> 1088) >>>> associated with the flow-spec draft >>>> (http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-05.txt ) >>>> we are going to re-WG-LC the document and rerun the publication >>>> process. >>>> >>>> The deadline for comments is 3/2/2009. >>>> >>>> Sue & Yakov. >>>> _______________________________________________ >>>> 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 tony.li@tony.li Sat Mar 7 00:25:51 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA5E3A6A5F for ; Sat, 7 Mar 2009 00:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVkD4SLzyXgy for ; Sat, 7 Mar 2009 00:25:51 -0800 (PST) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 3D85D3A67DA for ; Sat, 7 Mar 2009 00:25:51 -0800 (PST) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id Q8S61b0010EPchoA28SPJJ; Sat, 07 Mar 2009 08:26:23 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id Q8SM1b0033L8a8Q8M8SN65; Sat, 07 Mar 2009 08:26:23 +0000 Message-ID: <49B1B11D.6090007@tony.li> Date: Fri, 06 Mar 2009 15:26:21 -0800 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: John Leslie References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> <49B0E79F.6030506@raszuk.net> <3322C991-4504-477D-AB50-4D709154747F@juniper.net> <20090306145227.GA54798@verdi> In-Reply-To: <20090306145227.GA54798@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 08:25:52 -0000 John Leslie wrote: > So, while I'm not exactly _happy_ living in a world of Google > IPR filings, I'm a whole lot happier with that than a world of > Jupiter IPR filings. +1 Tony From paul@jakma.org Sat Mar 7 12:08:29 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE413A6B2B for ; Sat, 7 Mar 2009 12:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-HV6DW0-NxC for ; Sat, 7 Mar 2009 12:08:28 -0800 (PST) Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id 2C3AC3A6B23 for ; Sat, 7 Mar 2009 12:08:27 -0800 (PST) Received: from melandri.gla.jakma.org (melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.3/8.14.2) with ESMTP id n27K8mih005147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Mar 2009 20:08:56 GMT Date: Sat, 7 Mar 2009 20:08:47 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: John Leslie In-Reply-To: <20090306145227.GA54798@verdi> Message-ID: References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> <49B0E79F.6030506@raszuk.net> <3322C991-4504-477D-AB50-4D709154747F@juniper.net> <20090306145227.GA54798@verdi> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (hibernia.jakma.org [212.17.55.49]); Sat, 07 Mar 2009 20:08:57 +0000 (GMT) Cc: Inter-Domain Routing List Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 20:08:29 -0000 On Fri, 6 Mar 2009, John Leslie wrote: > Bottom line: I'd like to give Jupiter more time to think it over, > and not progress flow-spec to standard right yet. This seems the most prudent move all round for now (giving the lawyers more time to hone the language does not prejudice the existence of the specification, albeit in draft form). I.e.: No. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Kites rise highest against the wind -- not with it. -- Winston Churchill From danny@tcb.net Sun Mar 8 10:29:06 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB503A697E for ; Sun, 8 Mar 2009 10:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.045 X-Spam-Level: * X-Spam-Status: No, score=1.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BWvSCs35EPK for ; Sun, 8 Mar 2009 10:29:06 -0700 (PDT) Received: from sa.aa.arbor.net (unknown [204.181.64.1]) by core3.amsl.com (Postfix) with ESMTP id E5A4E3A6842 for ; Sun, 8 Mar 2009 10:29:05 -0700 (PDT) Received: from localhost (sa.aa.arbor.net [10.1.0.64]) by sa.aa.arbor.net (Postfix) with ESMTP id BD92B17036 for ; Sun, 8 Mar 2009 13:29:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at arbor.net Received: from 10-1-15-26.aa.arbor.net (10-1-15-26.aa.arbor.net [10.1.15.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sa.aa.arbor.net (Postfix) with ESMTP id A8F8016FE4 for ; Sun, 8 Mar 2009 13:29:37 -0400 (EDT) Message-Id: <2AA14FA8-54BB-4A21-BEB2-082E7E2DD5C0@tcb.net> From: Danny McPherson To: Inter-Domain Routing List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Mar 2009 11:29:36 -0600 References: <200902180030.n1I0UiM41233@magenta.juniper.net> <8390A4C9-ED55-4BD2-9E17-97CE15F96C40@cisco.com> <200903051704.n25H46M31971@magenta.juniper.net> <49B0E79F.6030506@raszuk.net> <3322C991-4504-477D-AB50-4D709154747F@juniper.net> <20090306145227.GA54798@verdi> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 17:29:06 -0000 I've avoided comment on this in detail as well, for a number of reasons - specifically, as a co-author, an implementer, one of the earliest evangelists, and very heavily pushing operational deployment, all after working with Juniper on implementation interoperability and spec refinement over the earlier years of the draft. Myself and *many* others helped push for this type of capability in the late 2002 and early 2003 timeframe, as it seemed a natural evolution to both destination and source-based blackhole routing, and some BGP community- based hacks that folks were doing already that provided some flow-specesque capabilities. Apparently, Juniper had a separate parallel effort underway as well. The fact that Robert, who was at Cisco at the time, was "fully aware about Juniper's authors filing the patent application for this work" surprises me, given that I certainly wasn't, and while I can't speak for others "authoritatively", I'm pretty sure Jared wasn't either. The necessity for third party disclosure here comes to mind, as Thomas pointed out, given that Robert was a co-author as well, and we all presumably subscribed to what was outlined in the boilerplate of every iteration of the draft. I've long understood the IETF IPR rules and the absolute need for disclosure - and this has certainly been cemented in my mind since I saw the flow-spec disclosure only a few months ago on a draft that had been baking since 2003. Personally, it's extremely disappointing to have invested a considerable amount of time and effort into internal development, interoperability testing with Juniper, spec refinement, and operational deployment and operational community education, only to find out some five years later that your co-authors have IPR claims in this area. So, to speak in fairness, I asked myself the question: would I have behaved differently had I known about the IPR? The answer was yes, certainly. As a matter of fact, my company has made several concerted decisions to avoid working on, or continuing work on, solutions based on technologies that are not openly available. When I talked to Pedro after the first disclosure and explained why this was such a concern, and engaged with several other colleagues (many of which I consider friends) at Juniper on the topic, I was pretty bitter at first. I did get pushback from one individual there, but that seems to have simply been the result of their lack of understanding of IETF process and related IPR rules - and why they're NOT simply "legalese", "mechanical", "overhead" "standards politics" - but absolutely necessary, and why not following these rules undermines the very foundation of open standards development. However, "it is what it is", and that's all water under the bridge now.. I can say that from my perspective Pedro and several other IETF participants from Juniper seem to have made virtuous efforts to remedy my concerns as an IETF participant and co-author, which are of course separate from the concerns of my employer. Furthermore, given that extreme tardiness of disclosure and the associated ill-effects was my chief concern, you can't completely ameliorate that. I do believe this incident has educated many folks, for the better, and hope to avoid predicaments of this sort in the future. All that said... I'm fine with the content of the disclosure, and believe the work has merit. There are other ways to accomplish the goals as well, but those are well beyond IDR and heavier if openly specified and using other machinery. I would like to see this document published, presumably as standards track. -danny From enkechen@cisco.com Mon Mar 9 17:31:32 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7102628C132 for ; Mon, 9 Mar 2009 17:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Cc7yosVKzL1 for ; Mon, 9 Mar 2009 17:31:31 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7CBF23A68C3 for ; Mon, 9 Mar 2009 17:31:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,332,1233532800"; d="txt'208?scan'208,208";a="139610105" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 10 Mar 2009 00:32:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2A0W585027115 for ; Mon, 9 Mar 2009 17:32:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2A0W5iw000502 for ; Tue, 10 Mar 2009 00:32:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 17:32:05 -0700 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 17:32:05 -0700 Message-ID: <49B5B505.6090409@cisco.com> Date: Mon, 09 Mar 2009 17:32:05 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Inter-Domain Routing List Content-Type: multipart/mixed; boundary="------------030005030505040902070705" X-OriginalArrivalTime: 10 Mar 2009 00:32:05.0623 (UTC) FILETIME=[A3810070:01C9A117] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2120; t=1236645126; x=1237509126; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20[Fwd=3A=20I-D=20Action=3Adraft-chen-rfc4893bis- 02.txt] |Sender:=20; bh=tBtcymA+fR2Cg2Zsj1vdMDgoXfexAVVq0vOt9vTmC+w=; b=Gjx4T2jC8qseSUHOOH6Xuadnis3u7laOw2J/vlRELVZhoWc7KNqF0s22OI /fYQYqcrsJRkp9U/gxRUVmExp8/Wl6Qjc8aPPb9FFriC/ni2dJg2VKIl7nRS 2pgXyA/x7e; Authentication-Results: sj-dkim-4; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 00:31:32 -0000 This is a multi-part message in MIME format. --------------030005030505040902070705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -- this revised version includes further clarifications in the Error Handling section. -- Enke -------- Original Message -------- Subject: I-D Action:draft-chen-rfc4893bis-02.txt Date: Sat, 7 Mar 2009 16:00:02 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Support for Four-octet AS Number Space Author(s) : Q. Vohra, E. Chen Filename : draft-chen-rfc4893bis-02.txt Pages : 11 Date : 2009-03-07 Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-rfc4893bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------030005030505040902070705 Content-Type: Message/External-body; name="draft-chen-rfc4893bis-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-chen-rfc4893bis-02.txt" Content-Type: text/plain Content-ID: <2009-03-07155303.I-D@ietf.org> --------------030005030505040902070705 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------030005030505040902070705-- From david.freedman@uk.clara.net Tue Mar 10 07:27:48 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221DA3A6A6D for ; Tue, 10 Mar 2009 07:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eUTNry4QcHc for ; Tue, 10 Mar 2009 07:27:47 -0700 (PDT) Received: from synchronicity.convergence.cx (unknown [IPv6:2001:a88:0:ffff:216:17ff:fea5:e34c]) by core3.amsl.com (Postfix) with ESMTP id 4401D3A6813 for ; Tue, 10 Mar 2009 07:27:46 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.69) (envelope-from ) id 1Lh2wM-00008V-6z; Tue, 10 Mar 2009 14:28:18 +0000 Message-ID: <49B67901.1010808@uk.clara.net> Date: Tue, 10 Mar 2009 14:28:17 +0000 From: David Freedman Organization: Claranet LImited User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 Newsgroups: gmane.ietf.idr To: Rob Shakir References: <4987469E.60207@cisco.com> <20090204113349.GF2227@bronze.eng.gxn.net> In-Reply-To: <20090204113349.GF2227@bronze.eng.gxn.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, quaizar.vohra@gmail.com Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:27:48 -0000 " In addition, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute of an UPDATE message. A NEW BGP speaker that receives these path segment types in the AS4_PATH attribute of an UPDATE message from an OLD BGP speaker MUST discard these path segments, adjust the relevant attribute fields accordingly, and continue processing the UPDATE message. This case SHOULD be logged locally for analysis. " Quoth Rob: > From my interpretation of the RFCs, the precedent that has been set is that when > a neighbour hands us invalid attributes, we will send a NOTIFICATION. The root > of the problems with rfc4893 are that we implemented this behaviour to an OLD > speaker that, from its perspective, was propagating completely valid attributes. > I would appreciate some feedback on whether rfc4893 should introduce > 'permissive' behaviour, where invalid attributes are discarded, and we attempt > to workaround the lack of them -- or whether we should still penalise the > invalid attribute by treating this UPDATE as WITHDRAW. I'm still of the opinion that we should discard/withdraw the update as appropriate, I'm still not comfortable about discarding attributes like this, especially where we see a mix of people both doing and not doing this during transition to the (eventual) standard. Is there nobody else who thinks this is a bad thing (tm) ? I'd much rather not have reachability to a prefix because somebody screwed up than risk having broken reachability and loops. Dave. From david.freedman@uk.clara.net Tue Mar 10 07:32:27 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10D828C124 for ; Tue, 10 Mar 2009 07:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE1taZVgOdP3 for ; Tue, 10 Mar 2009 07:32:27 -0700 (PDT) Received: from synchronicity.convergence.cx (unknown [IPv6:2001:a88:0:ffff:216:17ff:fea5:e34c]) by core3.amsl.com (Postfix) with ESMTP id 0E78428C0FE for ; Tue, 10 Mar 2009 07:32:26 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.69) (envelope-from ) id 1Lh30t-00008x-VB; Tue, 10 Mar 2009 14:32:59 +0000 Message-ID: <49B67A1B.7070805@uk.clara.net> Date: Tue, 10 Mar 2009 14:32:59 +0000 From: David Freedman Organization: Claranet LImited User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 Newsgroups: gmane.ietf.idr To: Rob Shakir References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> <49AD024D.5030902@raszuk.net> <20090304123312.GA29001@bronze.eng.gxn.net> In-Reply-To: <20090304123312.GA29001@bronze.eng.gxn.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:32:28 -0000 > Operationally -- I think that any 'harmful' implications of this issue are > well-handled by section 3 -- the requirement to provide debugging features > should allow operators to easily identify why this prefix has been withdrawn. http://tools.ietf.org/html/draft-scholl-idr-advisory-00 I'm waiting for this to hit the list. Tom is just back from hols though so expect delay. Dave. From andy@nosignal.org Tue Mar 10 07:45:08 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF493A6B40 for ; Tue, 10 Mar 2009 07:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbRm60JgBySL for ; Tue, 10 Mar 2009 07:45:07 -0700 (PDT) Received: from chilli.nosignal.org (chilli.nosignal.org [91.194.68.1]) by core3.amsl.com (Postfix) with ESMTP id 21F9D3A68C0 for ; Tue, 10 Mar 2009 07:45:07 -0700 (PDT) Received: from [78.33.75.38] (helo=78-33-75-38.static.enta.net) by chilli.nosignal.org with esmtpa (Exim 4.63) (envelope-from ) id 1Lh3Cd-0008UZ-K6 for idr@ietf.org; Tue, 10 Mar 2009 14:45:09 +0000 Message-Id: From: Andy Davidson To: idr@ietf.org In-Reply-To: <49B67901.1010808@uk.clara.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Mar 2009 14:45:38 +0000 References: <4987469E.60207@cisco.com> <20090204113349.GF2227@bronze.eng.gxn.net> <49B67901.1010808@uk.clara.net> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:45:08 -0000 On 10 Mar 2009, at 14:28, David Freedman wrote: > I'm still of the opinion that we should discard/withdraw the update > as appropriate, I'm still not comfortable about discarding > attributes like this, especially where we see a mix of people both > doing and not doing this during transition to the (eventual) > standard. Is there nobody else who thinks this is a bad thing (tm) ? In my opinion, it is much more preferable to drop a prefix than to have to deal with learning the prefix in several differently broken ways. Partial and unpredictable routing for the originator will be harder to debug than what seems to be no connectivity. Please, let's adopt Rob's original, simple, clean suggestion : - discard new prefixes which have broken AS4_PATH properties. - treat existing prefixes which subsequently break as a withdraw. - Log in any case. Kind regards, Andy Davidson From neil@domino.org Tue Mar 10 08:33:16 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACF73A6850 for ; Tue, 10 Mar 2009 08:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxeFunXMMBtZ for ; Tue, 10 Mar 2009 08:33:13 -0700 (PDT) Received: from defiant.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by core3.amsl.com (Postfix) with ESMTP id B1D323A68C7 for ; Tue, 10 Mar 2009 08:33:12 -0700 (PDT) Received: from webmail2.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by defiant.domino.org (Postfix) with ESMTP id C24C3A6C4A; Tue, 10 Mar 2009 15:33:45 +0000 (GMT) Received: from 62.208.225.86 (proxying for 148.185.70.8) (SquirrelMail authenticated user neil) by webmail2.domino.org with HTTP; Tue, 10 Mar 2009 15:33:45 -0000 (GMT) Message-ID: <62378.62.208.225.86.1236699225.squirrel@webmail2.domino.org> In-Reply-To: <49B67901.1010808@uk.clara.net> References: <4987469E.60207@cisco.com> <20090204113349.GF2227@bronze.eng.gxn.net> <49B67901.1010808@uk.clara.net> Date: Tue, 10 Mar 2009 15:33:45 -0000 (GMT) From: "Neil J. McRae" To: "David Freedman" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: idr@ietf.org, quaizar.vohra@gmail.com Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil@domino.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 15:33:16 -0000 On Tue, March 10, 2009 14:28, David Freedman wrote: > > Is there nobody else who thinks this is a bad thing (tm) ? I strongly agree with you Dave. > I'd much rather not have reachability to a prefix because somebody > screwed up than risk having broken reachability and loops. Or broken routing costing you an arm and a leg. This behaviour could be abused easily. -- Neil J. McRae -- Alive and Kicking. neil@DOMINO.ORG From wwwrun@core3.amsl.com Fri Feb 27 16:17:02 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 99CAB3A6B1F; Fri, 27 Feb 2009 16:17:02 -0800 (PST) To: roque@juniper.net, danny@arbor.net, nsheth@juniper.net, robert@raszuk.net, bgreene@juniper.net, jared@puck.nether.net From: IETF Secretariat Message-Id: <20090228001702.99CAB3A6B1F@core3.amsl.com> Date: Fri, 27 Feb 2009 16:17:02 -0800 (PST) X-Mailman-Approved-At: Tue, 10 Mar 2009 11:31:58 -0700 Cc: idr@ietf.org, yakov@juniper.net, dward@cisco.com, shares@ghs.com, ipr-announce@ietf.org Subject: [Idr] Posting of IPR Disclosure X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 00:17:02 -0000 Dear Pedro Roque Marques, Danny McPherson, Nischal Sheth, Robert Raszuk, Barry Greene, Jared Mauch: An IPR disclosure that pertains to your Internet-Draft entitled "Dissemination of flow specification rules" (draft-ietf-idr-flow-spec) was submitted to the IETF Secretariat on 2009-02-26 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Juniper's Statement of IPR related to draft-ietf-idr-flow-spec-05." The IETF Secretariat From rcallon@juniper.net Tue Mar 3 10:55:47 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D3B28C2B9 for ; Tue, 3 Mar 2009 10:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-A351nIZr9G for ; Tue, 3 Mar 2009 10:55:45 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id A441C3A6B29 for ; Tue, 3 Mar 2009 10:55:45 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSa19TH/e6cR+YPXUT5FA0J9FcoV7q/Ms@postini.com; Tue, 03 Mar 2009 10:56:13 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 3 Mar 2009 10:55:13 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 10:55:13 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 10:55:12 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99C31.92703D85" Date: Tue, 3 Mar 2009 13:55:07 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05D447BB@emailwf1.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] IPR related to the flow-spec I-D Thread-Index: AcmcIJhFY/AIs6tPS0eogM+Jk5E7hAADRwIQ References: <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> From: Ross Callon To: , "Thomas Narten" X-OriginalArrivalTime: 03 Mar 2009 18:55:12.0760 (UTC) FILETIME=[95385F80:01C99C31] X-Mailman-Approved-At: Tue, 10 Mar 2009 11:31:57 -0700 Cc: David Ward Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 18:55:47 -0000 ------_=_NextPart_001_01C99C31.92703D85 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I am not on the IDR email list, but Dave Ward forwarded Thomas' email to me. =20 The additional applications in the more recent Juniper disclosure are patents where the inventors have not been involved in the IDR working group, and are not authors of the flow spec document. Therefore the connection between the applications and the IDR document was not noticed until very recently (there is no requirement that all IETF participants pay attention to every document in every IETF working group just in case they happen to have IPR on it). In fact the disclosure was posted approximately one week after the connection was noticed.=20 =20 The text that you refer to talks about "contributors". It is my impression however that if someone notices IPR that applies to an IETF document then they are supposed to disclose it when the connection is discovered, even if neither the inventors nor the person noticing the connection are contributors to the document in question.=20 =20 Ross =20 =20 From: Thomas Narten Date: March 2, 2009 11:40:24 AM CST To: Yakov Rekhter Cc: idr@ietf.org Subject: Re: [Idr] IPR related to the flow-spec I-D =20 Yakov Rekhter writes: I'd like to explain a bit of the confusion surrounding the IPR disclosure issue. On 12/23/2008 Juniper disclosed IPR on the flow-spec draft (https://datatracker.ietf.org/ipr/1052/), but it contained an incorrect "terms" section. Actually, I believe there is slightly more to it than this. IIRC, the December disclosure only listed a single patent application. The revised one lists one patent (issued) plus 5 patent applications (no information available AFAICT). So the disclosure has been expanded to include significantly (?) more possible IPR compared with the original disclosure. Correct? That said, the revised terms are IMO an improvement. Thanks. The disclosure was removed at Juniper's request and resubmitted on 02/09/2009 with the proper "terms" section. Unfortunately, Juniper's legal team released a number of IPR disclosures on or about 12/23/2008 and had to remove and correct all of them so, the sudden flurry of activity may have been worrying to some. You may have seen many corrected IPR disclosures on the IETF's IPR webpage (https://datatracker.ietf.org/ipr/about/) and more are to come. Juniper intended no harm or malice by these actions and Juniper is working to make certain that disclosures are made in a more timely manner. Regardng timing. The flow-spec document lists 6 authors, four of them with Juniper affiliations. The flow spec document was originally submitted as draft-marques-idr-flow-spec-00.txt back in June, 2003. Two of the authors on that document listed Juniper affiliations at that time. It seems surprising that the IPR that Juniper has just disclosed was only "recently" filed. If so, it is likely that there is significant prior art (since the document has been published and under discussion for so long). On the other hand, if the IPR was filed quite some time ago (i.e., when the work started), it raises the question of whether one of the IETF's most basic IPR obligations as described in RFC 3979 has been followed: 6.1.1. A Contributor's IPR in his or her Contribution Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 6.6 which the Contributor believes Covers or may ultimately Cover his or her Contribution, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6. ... 6.2.1. Timing of Disclosure Under Section 6.1.1 The IPR disclosure required pursuant to section 6.1.1 must be made as soon as reasonably possible after the Contribution is published in an Internet Draft unless the required disclosure is already on file. ... =20 If a Contributor first learns of IPR in its Contribution that meets the conditions of Section 6.6, for example a new patent application or the discovery of a relevant patent in a patent portfolio, after the Contribution is published in an Internet-Draft, a disclosure must be made as soon as reasonably possible after the IPR becomes reasonably and personally known to the Contributor. Can the Contributers to this document please clarify the history and their role in it better w.r.t the IPR disclosures? I'm particularly concerned about the timing of the filing of the IPR and its subsequent disclosure. It seems rather odd that an ID that has been under discussion within the IETF for some 5 1/2 years would be subject of an IPR disclosure at such a late date (only after IETF LC starts) in the process. For example, do any of the patent applications list any of the document authors as inventors (and if so when was the application filed)? Or is this a case where the IETF contributers weren't involved in the patent application and wouldn't "reasonably" have been expected to known about it, i.e., as covered by the following in 3979: l. "Reasonably and personally known": means something an individual knows personally or, because of the job the individual holds, would reasonably be expected to know. This wording is used to indicate that an organization cannot purposely keep an individual in the dark about patents or patent applications just to avoid the disclosure requirement. But this requirement should not be interpreted as requiring the IETF Contributor or participant (or his or her represented organization, if any) to perform a patent search to find applicable IPR. It would be most helpful if all the contributers associated with the patent applications clarified their role to the WG, as was recently done in the case of draft-ietf-tcpm-tcp-auth-opt-03 in the TCPM WG. TCPM is also grappling with a disclosure made late in the process and the patent author in that case graciously published the patent application to help the WG in its deliberations on how to proceed. Thomas _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr =20 ------_=_NextPart_001_01C99C31.92703D85 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I am not on the IDR email list, = but Dave Ward forwarded Thomas' email to me.

 

=

The additional applications in the = more recent Juniper disclosure are patents where the inventors have not been involved in the IDR working group, and are not authors of the flow spec document. Therefore the connection between the applications and the IDR document was not noticed until very recently (there is no requirement = that all IETF participants pay attention to every document in every IETF working = group just in case they happen to have IPR on it).  In fact the disclosure was = posted approximately one week after the connection was noticed. =

 

=

The text that you refer to talks = about "contributors". It is my impression however that if someone = notices IPR that applies to an IETF document then they are supposed to disclose = it when the connection is discovered, even if neither the inventors nor the = person noticing the connection are contributors to the document in question. =

 

=

Ross

 

=

 

=

From: Thomas Narten <narten@us.ibm.com>=

Date: March 2, 2009 11:40:24 AM = CST

To: Yakov Rekhter <yakov@juniper.net>=

Subject: Re: [Idr] IPR related to the = flow-spec I-D

 

Yakov Rekhter <yakov@juniper.net> writes:


I'd like to explain a bit of the confusion surrounding the = IPR

disclosure issue. On 12/23/2008 Juniper disclosed IPR on the = flow-spec

draft (https://datatracker.ietf.= org/ipr/1052/), but it contained

an incorrect "terms" = section.


Actually, I believe there is slightly more to it than this. IIRC, = the
December disclosure only listed a single patent application. The
revised one lists one patent (issued) plus 5 patent applications (no
information available AFAICT). So the disclosure has been expanded = to
include significantly (?) more possible IPR compared with the = original
disclosure.

Correct?

That said, the revised terms are IMO an improvement. Thanks.


The disclosure was removed at Juniper's request and resubmitted = on

02/09/2009 with the proper "terms" section. = Unfortunately, Juniper's

legal team released a number of IPR disclosures on or = about

12/23/2008 and had to remove and correct all of them so, the = sudden

flurry of activity may have been worrying to some. You may have = seen

many corrected IPR disclosures on the IETF's IPR = webpage

(https://datatracker.ietf= .org/ipr/about/) and more are to

come. Juniper intended no harm or malice by these actions = and

Juniper is working to make certain that disclosures are made in = a

more timely manner.


Regardng timing. The flow-spec document lists 6 authors, four of = them
with Juniper affiliations.

The flow spec document was originally submitted as
draft-marques-idr-flow-spec-00.txt back in June, 2003. Two of the
authors on that document listed Juniper affiliations at that time.

It seems surprising that the IPR that Juniper has just disclosed was
only "recently" filed. If so, it is likely that there is = significant
prior art (since the document has been published and under = discussion
for so long). On the other hand, if the IPR was filed quite some = time
ago (i.e., when the work started), it raises the question of whether
one of the IETF's most basic IPR obligations as described in RFC = 3979
has been followed:

  6.1.1.  A Contributor's IPR in his or her = Contribution

  Any Contributor who reasonably and personally knows of IPR = meeting
  the conditions of Section 6.6 which the Contributor believes = Covers
  or may ultimately Cover his or her Contribution, or which = the
  Contributor reasonably and personally knows his or her = employer or
  sponsor may assert against Implementing Technologies based = on such
  Contribution, must make a disclosure in accordance with this Section
  6.

...

  6.2.1.  Timing of Disclosure Under Section 6.1.1

  The IPR disclosure required pursuant to section 6.1.1 must = be made as
  soon as reasonably possible after the Contribution is = published in an
  Internet Draft unless the required disclosure is already on = file.

...    

  If a Contributor first learns of IPR in its Contribution = that meets
  the conditions of Section 6.6, for example a new patent = application
  or the discovery of a relevant patent in a patent portfolio, = after
  the Contribution is published in an Internet-Draft, a = disclosure must
  be made as soon as reasonably possible after the IPR = becomes
  reasonably and personally known to the Contributor.

Can the Contributers to this document please clarify the history and
their role in it better w.r.t the IPR disclosures? I'm particularly
concerned about the timing of the filing of the IPR and its = subsequent
disclosure. It seems rather odd that an ID that has been under
discussion within the IETF for some 5 1/2 years would be subject of = an
IPR disclosure at such a late date (only after IETF LC starts) in = the
process.

For example, do any of the patent applications list any of the
document authors as inventors (and if so when was the application
filed)? Or is this a case where the IETF contributers weren't = involved
in the patent application and wouldn't "reasonably" have been expected
to known about it, i.e., as covered by the following in 3979:

  l. "Reasonably and personally known": means = something an individual
     knows personally or, because of the job = the individual holds,
     would reasonably be expected to know. =  This wording is used to
     indicate that an organization cannot = purposely keep an individual
     in the dark about patents or patent = applications just to avoid the
     disclosure requirement.  But this requirement should not be
     interpreted as requiring the IETF = Contributor or participant (or
     his or her represented organization, if = any) to perform a patent
     search to find applicable IPR.

It would be most helpful if all the contributers associated with the
patent applications clarified their role to the WG, as was recently
done in the case of draft-ietf-tcpm-tcp-auth-opt-03 in the TCPM
WG. TCPM is also grappling with a disclosure made late in the = process
and the patent author in that case graciously published the patent
application to help the WG in its deliberations on how to proceed.

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

 

------_=_NextPart_001_01C99C31.92703D85-- From yakov@juniper.net Tue Mar 10 12:41:18 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0043428C140 for ; Tue, 10 Mar 2009 12:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T98-Jdde6jYG for ; Tue, 10 Mar 2009 12:41:17 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 39DDB28C116 for ; Tue, 10 Mar 2009 12:41:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSbbCgE9UsVpQSS8+Vq8cXLeGxUOXTnZt@postini.com; Tue, 10 Mar 2009 12:41:53 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 10 Mar 2009 12:41:03 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 12:41:03 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 12:41:02 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Mar 2009 12:41:01 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2AJf2M14755 for ; Tue, 10 Mar 2009 12:41:02 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903101941.n2AJf2M14755@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26990.1236714061.1@juniper.net> Date: Tue, 10 Mar 2009 12:41:02 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 10 Mar 2009 19:41:01.0957 (UTC) FILETIME=[24C2CB50:01C9A1B8] Subject: [Idr] draft agenda X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 19:41:18 -0000 Folks, I posted the draft agenda for the upcoming IDR WG meeting. Yakov. From rjs@eng.gxn.net Tue Mar 10 13:24:50 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE2F28C0F5 for ; Tue, 10 Mar 2009 13:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKnMhTDfhPEV for ; Tue, 10 Mar 2009 13:24:49 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by core3.amsl.com (Postfix) with ESMTP id 3B5F03A6CBF for ; Tue, 10 Mar 2009 13:24:49 -0700 (PDT) Received: from rjs by cappuccino.rob.sh with local (Exim 4.69) (envelope-from ) id 1Lh8Tn-0001l2-5M; Tue, 10 Mar 2009 20:23:11 +0000 Date: Tue, 10 Mar 2009 20:23:11 +0000 From: Rob Shakir To: David Freedman Message-ID: <20090310202311.GC6735@cappuccino.rob.sh> References: <4987469E.60207@cisco.com> <20090204113349.GF2227@bronze.eng.gxn.net> <49B67901.1010808@uk.clara.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49B67901.1010808@uk.clara.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: idr@ietf.org, quaizar.vohra@gmail.com Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 20:24:50 -0000 On Tue, Mar 10, 2009 at 02:28:17PM +0000, David Freedman wrote: > Quoth Rob: > > > From my interpretation of the RFCs, the precedent that has been set is that when > > a neighbour hands us invalid attributes, we will send a NOTIFICATION. The root > > of the problems with rfc4893 are that we implemented this behaviour to an OLD > > speaker that, from its perspective, was propagating completely valid attributes. > > I would appreciate some feedback on whether rfc4893 should introduce > > 'permissive' behaviour, where invalid attributes are discarded, and we attempt > > to workaround the lack of them -- or whether we should still penalise the > > invalid attribute by treating this UPDATE as WITHDRAW. > > I'm still of the opinion that we should discard/withdraw the update as > appropriate, I'm still not comfortable about discarding attributes like > this, especially where we see a mix of people both doing and not doing > this during transition to the (eventual) standard. Whilst I appreciate that I am effectively agreeing with myself by proxy here -- the other issue that I feel that we should bear in mind is the fact that Enke and John have proposed the withdraw solution in draft-scudder-idr-optional-transitive. I cannot see how one can reconcile the behaviour that is suggested in this draft with the proposed rfc4893 draft. I think the question we have to ask is why, if there is some other draft that proposes it is reasonable to withdraw the prefix for /other/ broken attributes, it is not reasonable to standardise the behaviour here? I think that with the new draft in mind, there is no precedent for dropping the update, and we should standardise not being permissive to a BGP speaker who is broken. The key thing to remember here, as I see it, is that the speaker does not comply with the original RFC -- the only BGP speakers that we are penalising are broken by a standard that has already reached RFC. Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html From rjs@eng.gxn.net Tue Mar 10 13:30:16 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63D803A680A for ; Tue, 10 Mar 2009 13:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuvQtJGN3SKV for ; Tue, 10 Mar 2009 13:30:14 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by core3.amsl.com (Postfix) with ESMTP id BBF933A67DD for ; Tue, 10 Mar 2009 13:30:14 -0700 (PDT) Received: from rjs by cappuccino.rob.sh with local (Exim 4.69) (envelope-from ) id 1Lh8Z1-0001lD-80; Tue, 10 Mar 2009 20:28:35 +0000 Date: Tue, 10 Mar 2009 20:28:35 +0000 From: Rob Shakir To: David Freedman Message-ID: <20090310202835.GD6735@cappuccino.rob.sh> References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> <49AD024D.5030902@raszuk.net> <20090304123312.GA29001@bronze.eng.gxn.net> <49B67A1B.7070805@uk.clara.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49B67A1B.7070805@uk.clara.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 20:30:16 -0000 On Tue, Mar 10, 2009 at 02:32:59PM +0000, David Freedman wrote: > http://tools.ietf.org/html/draft-scholl-idr-advisory-00 > > I'm waiting for this to hit the list. > > Tom is just back from hols though so expect delay. Dave, Thanks for bringing this one to my attention! :-) I'll keep my comments on draft-scholl-idr-advisory-00 for the appropriate thread, but I think that this is not a replacement for draft-scudder-idr-optional-transitive (I don't think it is intended to be), since in this case, sending an advisory message to our directly connected neighbour will not help (since this draft applies only those attributes that have not been checked by them). Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html From david.freedman@uk.clara.net Tue Mar 10 16:31:03 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495323A67ED for ; Tue, 10 Mar 2009 16:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=1.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81H2DEJFeXtF for ; Tue, 10 Mar 2009 16:30:56 -0700 (PDT) Received: from staff00-mail.uk.clara.net (staff00-mail.uk.clara.net [80.168.69.91]) by core3.amsl.com (Postfix) with ESMTP id 7A60D3A676A for ; Tue, 10 Mar 2009 16:30:56 -0700 (PDT) Received: from eth3.gs-fw1.router.uk.clara.net ([80.168.52.244]:8542 helo=srvukfe01.claranet.local) by staff00-mail.uk.clara.net (staff00-mail.uk.clara.net [80.168.69.91]:25) with esmtp id 1LhBQ0-0007mf-2d (Exim 4.60) (return-path ); Tue, 10 Mar 2009 23:31:29 +0000 Received: from EXVS01.claranet.local ([192.168.201.205]) by srvukfe01.claranet.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Mar 2009 23:30:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A1D8.3CE2D7F5" Date: Tue, 10 Mar 2009 23:30:17 -0000 Message-ID: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD24@EXVS01.claranet.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: New Version Notification fordraft-scudder-idr-optional-transitive-00 Thread-Index: Acmhv1izauijNE4lTWiuVok4Gqxe+wAGNLGH References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <03131F77-4505-4BD0-8ED9-B07776252E4C@tcb.net> <49AD024D.5030902@raszuk.net> <20090304123312.GA29001@bronze.eng.gxn.net> <49B67A1B.7070805@uk.clara.net> <20090310202835.GD6735@cappuccino.rob.sh> From: "David Freedman" To: "Rob Shakir" X-OriginalArrivalTime: 10 Mar 2009 23:30:46.0000 (UTC) FILETIME=[3CB0D700:01C9A1D8] X-BorderScout-FS-Score: 0 X-BorderScout-CM-Score: 0 X-BorderScout-CA-Score: 0 X-FSecure: clean X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification fordraft-scudder-idr-optional-transitive-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 23:31:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A1D8.3CE2D7F5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, actually this draft will aid the "debugging" as quoted=20 ------------------------------------------------ David Freedman Group Network Engineering=20 Claranet Limited http://www.clara.net -----Original Message----- From: Rob Shakir [mailto:rjs@eng.gxn.net] Sent: Tue 3/10/2009 20:28 To: David Freedman Cc: John G. Scudder; idr List Subject: Re: Fwd: New Version Notification = fordraft-scudder-idr-optional-transitive-00 =20 On Tue, Mar 10, 2009 at 02:32:59PM +0000, David Freedman wrote: > http://tools.ietf.org/html/draft-scholl-idr-advisory-00 >=20 > I'm waiting for this to hit the list. >=20 > Tom is just back from hols though so expect delay. Dave, Thanks for bringing this one to my attention! :-) I'll keep my comments on draft-scholl-idr-advisory-00 for the = appropriate thread, but I think that this is not a replacement for draft-scudder-idr-optional-transitive (I don't think it is intended to = be), since in this case, sending an advisory message to our directly = connected neighbour will not help (since this draft applies only those attributes = that have not been checked by them). Kind regards, Rob --=20 Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html ------_=_NextPart_001_01C9A1D8.3CE2D7F5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Fwd: New Version Notification = fordraft-scudder-idr-optional-transitive-00

No, actually this draft will aid the = "debugging" as quoted
------------------------------------------------
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net



-----Original Message-----
From: Rob Shakir [mailto:rjs@eng.gxn.net]
Sent: Tue 3/10/2009 20:28
To: David Freedman
Cc: John G. Scudder; idr List
Subject: Re: Fwd: New Version Notification   = fordraft-scudder-idr-optional-transitive-00

On Tue, Mar 10, 2009 at 02:32:59PM +0000, David Freedman wrote:
> http://t= ools.ietf.org/html/draft-scholl-idr-advisory-00
>
> I'm waiting for this to hit the list.
>
> Tom is just back from hols though so expect delay.

Dave,

Thanks for bringing this one to my attention! :-)

I'll keep my comments on draft-scholl-idr-advisory-00 for the = appropriate
thread, but I think that this is not a replacement for
draft-scudder-idr-optional-transitive (I don't think it is intended to = be),
since in this case, sending an advisory message to our directly = connected
neighbour will not help (since this draft applies only those attributes = that
have not been checked by them).

Kind regards,
Rob

--
Rob = Shakir           &= nbsp;          = <rjs@eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus = Solutions
ddi: +44208 587 = 6077            = mob: +44797 155 4098
pgp: = 0xc07e6deb          &nb= sp;      nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html

------_=_NextPart_001_01C9A1D8.3CE2D7F5-- From anantha@juniper.net Wed Mar 11 15:32:37 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD7B28C20E for ; Wed, 11 Mar 2009 15:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGRSZ0Ji45AE for ; Wed, 11 Mar 2009 15:32:36 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 12EAD28C0F1 for ; Wed, 11 Mar 2009 15:32:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSbg8I+7D75UmSc0fYzHpix5Yo9vNetxC@postini.com; Wed, 11 Mar 2009 15:33:13 PDT Received: from juniper (172.24.24.171) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.1.340.0; Wed, 11 Mar 2009 15:31:40 -0700 Received: by juniper (Postfix, from userid 8228) id A92D259D3A2; Wed, 11 Mar 2009 15:31:40 -0700 (PDT) Date: Wed, 11 Mar 2009 15:31:40 -0700 From: Ananth Suryanarayana To: enkechen@cisco.com Message-ID: <20090311223140.GU11605@anantha-lnx.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: idr@ietf.org Subject: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 22:32:37 -0000 Hi, According to the spec.. A NEW BGP speaker that receives malformed AS4_PATH attribute in an UPDATE message from an OLD BGP speaker MUST discard the attribute, and continue processing the UPDATE message. The error SHOULD be logged locally for analysis. 1. Can this phrase "continue further processing" be further clarified ? According to [OPT-ATTR-E], malformed optional-transitive-partial attributes must be discarded and handled as withdraws instead. I believe we should do the same here. 2. Though, it is expected that AS4Path and [Aggregator4] attribures sent from Old speakers are marked 'partial', if it is not done so, should they still be treated as withdraws (because we know that peer is Old Spekaer from capabilities negotiated). I would think so. (Though only relying on the partial bit in the attribute flags makes all (except may be Aggregator4) malformed otional-transitive-partial attributes processing consistent. Thanks -- Regards, Ananth -- ----- Forwarded message from Enke Chen ----- Date: Mon, 9 Mar 2009 17:32:05 -0700 From: Enke Chen To: Inter-Domain Routing List Subject: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt] FYI -- this revised version includes further clarifications in the Error Handling section. -- Enke -------- Original Message -------- Subject: I-D Action:draft-chen-rfc4893bis-02.txt Date: Sat, 7 Mar 2009 16:00:02 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Support for Four-octet AS Number Space Author(s) : Q. Vohra, E. Chen Filename : draft-chen-rfc4893bis-02.txt Pages : 11 Date : 2009-03-07 Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-rfc4893bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ----- End forwarded message ----- From enkechen@cisco.com Wed Mar 11 16:26:01 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665F63A6959 for ; Wed, 11 Mar 2009 16:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW+MT7++aIGC for ; Wed, 11 Mar 2009 16:26:00 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5DF173A6957 for ; Wed, 11 Mar 2009 16:26:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,346,1233532800"; d="scan'208";a="154418997" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 11 Mar 2009 23:26:37 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2BNQbZs028510; Wed, 11 Mar 2009 16:26:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2BNQa3W027806; Wed, 11 Mar 2009 23:26:36 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 16:26:36 -0700 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 16:26:36 -0700 Message-ID: <49B848AC.6080908@cisco.com> Date: Wed, 11 Mar 2009 16:26:36 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Ananth Suryanarayana References: <20090311223140.GU11605@anantha-lnx.juniper.net> In-Reply-To: <20090311223140.GU11605@anantha-lnx.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2009 23:26:36.0459 (UTC) FILETIME=[D25DA7B0:01C9A2A0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3019; t=1236813997; x=1237677997; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Idr]=20[Fwd=3A=20I-D=20Action=3Adraft- chen-rfc4893bis-02.txt] |Sender:=20; bh=4SjYx3shUP4G9QgfcM4POd+XiVy6Fz18kFCOEEQyzDM=; b=szAnqOvZHK5R+9hSCg95K5nG7D/knuD+yp1UHIPVkFIhru96LJl/MWlC0w OzRml2Is38d5fUyTQqgQankAZY1aYJ06qox4u9L63G7WTgSqqO4U7FCd6zXR bQVbboe1HV; Authentication-Results: sj-dkim-2; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: idr@ietf.org Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 23:26:01 -0000 Hi, Ananth: On your comment #1: [OPT-ATTR-E] provides two options for handling a malformed optional transitive attribute: 1) Treat as withdraw. 2) Discard the attribute. Currently the rfc4893bis specifies the "Discard the attribute" option (thus favors reachability) for a malformed AS4_PATH attribute from an OLD speaker due to the following considerations: - During the transition, the 2byte AS numbers will dominant. So the as-path loop detection will be intact across the 2byte AS domains. - The possible routing loop (due to loss of AS4 info) would be broken somewhere, as pointed out by John Scudder). - Other side effects (such as potential oscillation) are highly topology and policy dependent, and should be rare. In case of a real side effect, operator intervention (such as applying a filter) would be required, as with the "Treat as withdraw" option. However, such intervention would be on a needed based, instead of immediate for the "Treat as withdraw" option. In the case of a malformed AS4_PATH attribute, there is really no perfect solution. The tradeoff is between preserving the reachability and dealing with potential side effects. As currently specified, rfc4893bis favors reachability. On your comment #2: The partial bit should have been set for the AS4_PATH or AS4_AGGREGATOR from an OLD speaker. If it is not set, it is covered by [OPT-ATTR-E]: In the specific case of incorrect path attribute flag bits -- i.e., a path attribute that is known by its type code to be Optional and Transitive but whose flag bits are not set accordingly -- the behavior specified by [RFC4271] SHALL be followed. (Consider that in the case of such an error, the "tunneling" argument given above does not apply, by definition.) Although the speaker at fault is punished, one can argue that it is a bit harsh for a recoverable error. Thanks. -- Enke Ananth Suryanarayana wrote: > Hi, > > According to the spec.. > > A NEW BGP speaker that receives malformed AS4_PATH attribute in an > UPDATE message from an OLD BGP speaker MUST discard the attribute, > and continue processing the UPDATE message. The error SHOULD be > logged locally for analysis. > > 1. Can this phrase "continue further processing" be further clarified ? > According to [OPT-ATTR-E], malformed optional-transitive-partial attributes > must be discarded and handled as withdraws instead. I believe we should > do the same here. > > 2. Though, it is expected that AS4Path and [Aggregator4] attribures sent from > Old speakers are marked 'partial', if it is not done so, should they still > be treated as withdraws (because we know that peer is Old Spekaer from > capabilities negotiated). I would think so. (Though only relying on the > partial bit in the attribute flags makes all (except may be Aggregator4) > malformed otional-transitive-partial attributes processing consistent. > > Thanks > From yakov@juniper.net Mon Mar 16 07:12:26 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA1B28C172 for ; Mon, 16 Mar 2009 07:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBLbLuKnKqre for ; Mon, 16 Mar 2009 07:12:25 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 83D8028C121 for ; Mon, 16 Mar 2009 07:12:25 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSb5ec8cNwXI1oI+FC+ZnxdFK3T4LH2Kj@postini.com; Mon, 16 Mar 2009 07:13:07 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 16 Mar 2009 07:00:20 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Mar 2009 07:00:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Mar 2009 07:00:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 07:00:19 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2GE0IM21996 for ; Mon, 16 Mar 2009 07:00:18 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903161400.n2GE0IM21996@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38533.1237212018.1@juniper.net> Date: Mon, 16 Mar 2009 07:00:18 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 16 Mar 2009 14:00:19.0832 (UTC) FILETIME=[8AC88F80:01C9A63F] Subject: [Idr] final agenda X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 14:12:26 -0000 Folks, I posted the final agenda for the upcoming IDR WG meeting. Yakov. From narten@us.ibm.com Thu Mar 19 09:04:54 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C7D28C165 for ; Thu, 19 Mar 2009 09:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.266 X-Spam-Level: X-Spam-Status: No, score=-4.266 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZsODEyjeD5D for ; Thu, 19 Mar 2009 09:04:53 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id BF7FF28C148 for ; Thu, 19 Mar 2009 09:04:53 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2JG5DpZ008993 for ; Thu, 19 Mar 2009 10:05:13 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2JG5Mvf197170 for ; Thu, 19 Mar 2009 10:05:25 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2JG5Gtk004616 for ; Thu, 19 Mar 2009 10:05:21 -0600 Received: from cichlid.raleigh.ibm.com ([9.65.218.255]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2JG57f9004316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 10:05:09 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n2JG56Zj020554; Thu, 19 Mar 2009 12:05:07 -0400 Message-Id: <200903191605.n2JG56Zj020554@cichlid.raleigh.ibm.com> To: Ross Callon In-reply-to: <3525C9833C09ED418C6FD6CD9514668C05D447BB@emailwf1.jnpr.net> References: <200903021740.n22HeOpp028017@cichlid.raleigh.ibm.com> <3525C9833C09ED418C6FD6CD9514668C05D447BB@emailwf1.jnpr.net> Comments: In-reply-to Ross Callon message dated "Tue, 03 Mar 2009 13:55:07 -0500." Date: Thu, 19 Mar 2009 12:05:06 -0400 From: Thomas Narten Cc: idr@ietf.org, David Ward Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 16:04:54 -0000 [playing catchup now...] Ross, > The additional applications in the more recent Juniper disclosure are > patents where the inventors have not been involved in the IDR working > group, and are not authors of the flow spec document. Therefore the > connection between the applications and the IDR document was not noticed > until very recently (there is no requirement that all IETF participants > pay attention to every document in every IETF working group just in case > they happen to have IPR on it). In fact the disclosure was posted > approximately one week after the connection was noticed. Thanks for this. To be clear, the above is 100% consistent with IETF IPR rules. Folks who hold IPR but are not participating in a particular effort are not expected or required to make disclosures. Again, disclosures are needed when: 6.1.1. A Contributor's IPR in his or her Contribution Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 6.6 which the Contributor believes Covers or may ultimately Cover his or her Contribution, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6. And "Contributer" specifically refers to folk that are participating in the effort. Thomas From narten@us.ibm.com Thu Mar 19 09:51:27 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF733A6A41 for ; Thu, 19 Mar 2009 09:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzl3fyNtcvNe for ; Thu, 19 Mar 2009 09:51:26 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 9C7503A690E for ; Thu, 19 Mar 2009 09:51:26 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2JGnU08020159 for ; Thu, 19 Mar 2009 10:49:30 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2JGq8vQ208260 for ; Thu, 19 Mar 2009 10:52:09 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2JGq8q5005328 for ; Thu, 19 Mar 2009 10:52:08 -0600 Received: from cichlid.raleigh.ibm.com ([9.65.218.255]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2JGq08E005091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Mar 2009 10:52:07 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n2JGpxd1028354; Thu, 19 Mar 2009 12:52:00 -0400 Message-Id: <200903191652.n2JGpxd1028354@cichlid.raleigh.ibm.com> To: John Leslie In-reply-to: <20090305162646.GB65762@verdi> References: <200903051547.n25FlZM96518@magenta.juniper.net> <20090305162646.GB65762@verdi> Comments: In-reply-to John Leslie message dated "Thu, 05 Mar 2009 11:26:46 -0500." Date: Thu, 19 Mar 2009 12:51:59 -0400 From: Thomas Narten Cc: idr@ietf.org Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 16:51:28 -0000 John Leslie writes: > > From: Ross Callon > >> From: Thomas Narten > >> > >> IIRC, the December disclosure only listed a single patent application. > >> The revised one lists one patent (issued) plus 5 patent applications > >> (no information available AFAICT). So the disclosure has been expanded to > >> include significantly (?) more possible IPR compared with the original > >> disclosure. > (It is a significant annoyance to those of us without "free" access to > patent applications not published by the US patent office to be left > guessing what IPR claims may be being disclosed.) My understanding is that all patent applications that are public are findable via the free http://patft.uspto.gov/ web site. However, anyone applying for a patent may request that it remain private until it is issued. My assumption is that that is the situation we are in here, since I have not been able to access any of the applications either. > > The additional applications in the more recent Juniper disclosure are > > patents where the inventors have not been involved in the IDR working > > group, and are not authors of the flow spec document. > I am certainly happy to take Ross's word for this -- but additional > possible (unknown) IPR claims still leave me wondering... There is always the possibility (some would say likelyhood) of additional, unknown patents covering any given IETF document. Not much we can do about the unknown. > > Therefore the connection between the applications and the IDR document > > was not noticed until very recently (there is no requirement that all > > IETF participants pay attention to every document in every IETF working > > group just in case they happen to have IPR on it). > Indeed -- I hope nobody is asking to add such a requirement. The IPR WG (when it discussed this in the past) understood this reality very well. Hence, the disclosure rules apply to "contributers" to an effort. If you aren't participating in an effort, you don't have to worry about making disclosures. > > The text that you refer to talks about "contributors". It is my > > impression however that if someone notices IPR that applies to an IETF > > document then they are supposed to disclose it when the connection is > > discovered, even if neither the inventors nor the person noticing the > > connection are contributors to the document in question. > That is the way I read it, also. > As far as the additional patent applications being listed, I fear > we have to accept this: the requirement of "contributors" to disclose > IPR claims they become aware of is unambiguous, while their ability > to disclose the particulars of those claims is often severely limited > by company policy. Right. Like it or not, this is reality. Many companies consider patent applications "confidential". This is one reason why the IPR rules don't *require* that patent applications be made available to WGs. > In this particular case, we're faced with a late disclosure (the > December one, not the revision), and serious reason to believe that > a "contributor" was aware of IPR claims but trusted Juniper lawyers to > handle the disclosure. Lawyers habitually put things off as long as > possible; and that's the behavior we'd like to change. Sorry, while it may be somewhat true, I don't agree with the implication. It is the contributor's responsibility to make disclosures. If they have to go through their own lawyers first (which I would strongly advise!), they need to keep pushing on them to come to closure. > We have two "sticks" we might apply: > 1) asking for actual "royalty-free" terms, not Mutually-Assured- > Destruction terms, based upon either the late filing or the > vagueness of the claims disclosed; > 2) refusing to proceed until the actual claims in all disclosed patent > applications are available to all WG participants. > Under the circumstances, I think either of these would be > reasonable; though I could probably live with an assurance that the > Juniper lawyers are willing to change their ways and that Juniper > "contributors" will not in the future tolerate lenghty delays by > Juniper lawyers. Without taking a particular stance on how the WG should proceed, I do think it is worth noting that the WG has a number of options on what to do. Many may not be particularly attractive, or may not be particularly realistic. Some options: 1) do nothing. I.e., forward the document on Standards Track to the IESG anyway, Actually, this isn't "doing nothing", this needs to be "the WG has considered the IPR disclosures, but believes that publishing this document on standards track still is the best thing to do, all things considered". 2) publish as info/experimental rather than on standards track. 3) Table the document, and try to extract more attractive licensing terms from the IPR holder first. This approach could take a long time, and there are no assurances better terms could be obtained. Moreover, could the WG even agree on what would be acceptable terms? (The definition of what are "acceptable" terms tends to vary among different folk.) 4) Kill the document outright. I.e, to punish the IPR holders for failing to disclose. (And note, I'm talking specifically about the patent that should have been disclosed many years ago). Or something else. Overall, the WG needs to be realistic about what its options are and then make a decision about how to proceed. The worst thing it could do is simply not decide and leave the issue of what to do with the document unresolved indefinitely... Thomas From swb@employees.org Thu Mar 19 13:58:20 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D623A6B0B for ; Thu, 19 Mar 2009 13:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCP3-1ihg4qB for ; Thu, 19 Mar 2009 13:58:19 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1431D3A68EF for ; Thu, 19 Mar 2009 13:58:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,391,1233532800"; d="scan'208";a="40014378" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Mar 2009 20:59:04 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2JKx44d017363 for ; Thu, 19 Mar 2009 16:59:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2JKx4WT006610 for ; Thu, 19 Mar 2009 20:59:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 16:59:04 -0400 Received: from cisco.com ([10.86.245.243]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 16:59:03 -0400 Date: Thu, 19 Mar 2009 16:58:54 -0400 From: Scott Brim To: idr@ietf.org Message-ID: <20090319205854.GN60348@cisco.com> References: <200903051547.n25FlZM96518@magenta.juniper.net> <20090305162646.GB65762@verdi> <200903191652.n2JGpxd1028354@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903191652.n2JGpxd1028354@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-OriginalArrivalTime: 19 Mar 2009 20:59:03.0938 (UTC) FILETIME=[89282620:01C9A8D5] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [Idr] IPR related to the flow-spec I-D X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 20:58:20 -0000 Excerpts from Thomas Narten on Thu, Mar 19, 2009 12:51:59PM -0400: > > In this particular case, we're faced with a late disclosure > > (the December one, not the revision), and serious reason to > > believe that a "contributor" was aware of IPR claims but > > trusted Juniper lawyers to handle the disclosure. Lawyers > > habitually put things off as long as possible; and that's the > > behavior we'd like to change. > > Sorry, while it may be somewhat true, I don't agree with the > implication. It is the contributor's responsibility to make > disclosures. If they have to go through their own lawyers first > (which I would strongly advise!), they need to keep pushing on them > to come to closure. and keep mum while it's happening. From yakov@juniper.net Thu Mar 19 19:18:55 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93CFA3A684E for ; Thu, 19 Mar 2009 19:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPVa2fGvDvWj for ; Thu, 19 Mar 2009 19:18:54 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id A5A173A63EC for ; Thu, 19 Mar 2009 19:18:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKScL9PFGLmi1O45gaNHAZqQjCqrO6q2Np@postini.com; Thu, 19 Mar 2009 19:19:41 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 19 Mar 2009 19:19:14 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Mar 2009 19:19:14 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Mar 2009 19:19:13 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 19:19:12 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2K2JCM29497 for ; Thu, 19 Mar 2009 19:19:12 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903200219.n2K2JCM29497@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <53783.1237515552.1@juniper.net> Date: Thu, 19 Mar 2009 19:19:12 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 20 Mar 2009 02:19:12.0951 (UTC) FILETIME=[429EEC70:01C9A902] Subject: [Idr] slides for presentation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 02:18:55 -0000 Folks, Those who are presenting at the upcoming IDR WG meeting, please send me your slides as soon as possible, as I would like to make them available to the WG prior to the meeting. Yakov. From yakov@juniper.net Tue Mar 24 06:50:33 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851F628C253 for ; Tue, 24 Mar 2009 06:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsrO7Fs9kWTR for ; Tue, 24 Mar 2009 06:50:32 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 501EA28C10B for ; Tue, 24 Mar 2009 06:50:32 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKScjlW51Dd9hpDZL44NatUoyEPXXHL4ye@postini.com; Tue, 24 Mar 2009 06:51:23 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Mar 2009 06:48:55 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 06:48:55 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 06:48:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 06:48:54 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2ODmsM85223 for ; Tue, 24 Mar 2009 06:48:54 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903241348.n2ODmsM85223@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <17454.1237902534.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 06:48:54 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 24 Mar 2009 13:48:54.0615 (UTC) FILETIME=[45AABE70:01C9AC87] Subject: [Idr] minutes of IDR meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 13:50:33 -0000 Folks, Attached are minutes of IDR meeting. The deadline for comments is 3/31/2009. Yakov. ----------------------------------------------------------------- IDR Working Group Meeting IETF 74 Monday 23 March 2009 Chairs: Yakov Rekhter, Sue Hares Minutes: Geoff Huston 1. Document Status Update Since the last WG meeting there have been 3 published RFCs, adopted 3 drafts as WG documents and had 2 new protocol parameter registries established. The BGP MIB2 draft will go to WG Last Call after this IETF meeting. Proposed WG procedures for documents calls for a wait period of up to 12 months following WG Last Call for an implementation report that details two (or more) independent implementations of the document that conform to the document's specifications as a precondition for passing the document to the IESG. Yakov noted the IPR disclosure on the flow spec draft, and polled the WG as to whether the document should be passed to the IESG. The consensus of the WG was to proceed with this document and pass it to the IESG. 2. draft-rfernando-idr-link-bandwidth-00.txt (See presentation slides) Draft proposes the use of an extended community to carry the link's bandwidth. There was discussion of the proposed use of a 2 byte AS number field and the explicit use of AS-TRANS for 4-byte AS representation. In WG discussion of this 2 byte field for the AS number value, The presenter claimed that the AS was present as a well-defined way of using this community, and the AS field had no intended semantic interpretation, as this community was intended to be used in a non-transitive fashion. This 2 byte AS number field also allowed 4 bytes for the specification of the bandwidth value. All those at the WG session who had read the document had no objection to adoption of this draft as a WG document. This question will be taken to the mailing list by the chairs. 3. draft-scudder-idr-optional-transitive-01.txt Enke Chen described the material presented in the drafts. (See presentation slides) Draft proposes a change to the behaviour as specified in RFC4271 such that the detection of a malformed optional transitive attribute should not necessarily cause a NOTIFICATION and a BGP peer session reset. The draft proposes that each optional transitive community define the behaviour for treatment of malformed versions of the attribute, and this can also include the option to discard the malformed optional transitive attribute under certain circumstances, or treat an update that contains such an optional transitive update as a withdrawal and obviate the need to perform a NOTIFICATION and peer reset under all circumstances. The treatment of malformed AS4_PATH attributes was cited as an example of the inappropriateness of the current NOTIFICATION response. It was noted that the responses of discarding the attribute or discarding the withdrawal both represented compromises, and that the appropriate behaviour may vary according to the intended purpose of the attribute. Accordingly, the draft notes that future specifications that propose optional transitive attributes MUST specify what an error is, and how it must be handled All those at the WG session who had read the document had no objection to adoption of this draft as a WG document. This question will be taken to the mailing list by the chairs. 4. draft-chen-rfc4893bis-02.txt The author described the material presented in the drafts. (See presentation slides) The draft is an update on RFC4893, that contains some editorial clarifications and some changes to the specification. The changes focus on handling malformed optional transitive attributes in the AS4-AGGREGATOR and AS4_PATH. The draft proposes specific responses for malformed attributes according to the context of the error (whether receiver from OLD or NEW BGP peer), and notes that the options of attribute discard or implicit withdraw have potential advantages and disadvantages. Discussion on whether dropping a malformed AS4_PATH attribute, with the consequent implications for the operation of BGP loop detection or to perform an implicit withdraw was an appropriate action. The chair noted that this was an operational issue with some pressing time constraints and a need for a timely pragmatic response from the WG on this. All those at the WG session who had read the document had no objection to adoption of this draft as a WG document. This question will be taken to the mailing list by the chairs. 5. draft-knoll-idr-qos-attribute, draft-knoll-idr-cos-interconnect The author described the material presented in the drafts. (See presentation slides) Not many WG members had read the draft. The chairs noted that the drafts would need greater levels of WG attention before making a WG decision on adoption or not. 6. draft-scholl-idr-advisory-00.txt The author described the material presented in the drafts. (See presentation slides) Discussion on the draft noted a previous draft relating to a BGP inform capability and requested further information on how this draft differs from the earlier contribution. The potential to use such a mechanism to perform max prefix negotiation (offer / accept) between peers was discussed. WG members also commented on the issues involved with extracting such messages from BGP logs and referring such items to operational personnel and compared this approach to the current practices for operational communications. The draft author indicated an intention to apply this feedback to the draft. 7. draft-rosen-idr-aigp-00.txt =96 15 mins An author described the material presented in the draft. (See presentation slides) This draft describes an eBGP signalling mechanism using an optional transitive attribute intended to support MPLS environments where the network is configured using multiple AS's where the IGP metric across an AS can be communicated to neighboring AS's via this mechanism. Discussion concerned the relationship with this proposed approach and cost communities with MEDs, the nature of the operational requirements that motivated this proposed mechanism and the issue of possible impact of information leakage of this attribute beyond the intended community of use. Of the WG members who had read the draft there was no clear indication of a preference to adopt the draft as a WG item or not. The chairs will take the question to the mailing list. 8. IPR Presentation On behalf of the WG Yakov thanked Dave Ward for his support to the WG as Routing AD, with a round of applause from the WG. (See presentation slides) The presentation highlighted the responsibility of IETF participants to perform a timely disclosure of known IPR and that participants may wish to disclose knowledge of third party IPR, and that all participants should always assume that they need to know more about possible IPR than they currently know. The WG can makes its own decision about how it wishes to handle IPR and may do so either as a general procedure or on a case-by-case basis. Discussion noted that the IETF's IPR processes are the outcome of many years of efforts and are about transparency of process as well as allowing the WG's work to proceed, and the outcomes represent certain levels of compromise that reflect a broader issue of appropriate handling of IPR on a global scale. From yakov@juniper.net Tue Mar 24 06:55:16 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BD63A6A63 for ; Tue, 24 Mar 2009 06:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OiZgSU2lB8B for ; Tue, 24 Mar 2009 06:55:15 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 7EB473A6902 for ; Tue, 24 Mar 2009 06:55:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKScjmdiSEsZdz+AIMYO2Gi/ovcCdV5pmK@postini.com; Tue, 24 Mar 2009 06:56:07 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Mar 2009 06:53:47 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 06:53:46 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 06:53:46 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 06:53:45 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2ODrjM87973 for ; Tue, 24 Mar 2009 06:53:45 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903241353.n2ODrjM87973@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17726.1237902816.1@juniper.net> Date: Tue, 24 Mar 2009 06:53:45 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 24 Mar 2009 13:53:45.0813 (UTC) FILETIME=[F33C0850:01C9AC87] Subject: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 13:55:16 -0000 Folks, At the IDR WG meeting yesterday we had a fairly strong consensus for accepting draft-rfernando-idr-link-bandwidth-00.txt as an IDR WG document. Given that, unless we have a fairly strong consensus on the mailing list against accepting this draft, the draft will be accepted as an IDR WG document. The deadline for comments is April 6, 2009. Yakov. From yakov@juniper.net Tue Mar 24 06:57:01 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF7028C2A0 for ; Tue, 24 Mar 2009 06:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcbTHai7xQHS for ; Tue, 24 Mar 2009 06:57:00 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id CA88D28C29E for ; Tue, 24 Mar 2009 06:57:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKScjm4NyJSBfomK684sT8QWTwvtEqxhw0@postini.com; Tue, 24 Mar 2009 06:57:52 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Mar 2009 06:55:20 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 06:55:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 06:55:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 06:55:19 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2ODtJM88791 for ; Tue, 24 Mar 2009 06:55:19 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903241355.n2ODtJM88791@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17792.1237902919.1@juniper.net> Date: Tue, 24 Mar 2009 06:55:19 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 24 Mar 2009 13:55:19.0576 (UTC) FILETIME=[2B1F2180:01C9AC88] Subject: [Idr] draft-scudder-idr-optional-transitive-01.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 13:57:01 -0000 Folks, At the IDR WG meeting yesterday we had a very strong consensus for accepting draft-scudder-idr-optional-transitive-01.txt as an IDR WG document. Given that, unless we have a fairly strong consensus against accepting this draft, the draft will be accepted as an IDR WG document. The deadline for comments is April 6, 2009. Yakov. From yakov@juniper.net Tue Mar 24 06:58:21 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A876528C2A8 for ; Tue, 24 Mar 2009 06:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkdOZHW33KCO for ; Tue, 24 Mar 2009 06:58:21 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id E1C0428C29E for ; Tue, 24 Mar 2009 06:58:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKScjnMHHFglZgk0LVfKvo89rv8fFwh8ln@postini.com; Tue, 24 Mar 2009 06:59:12 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Mar 2009 06:57:03 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 06:57:03 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 06:57:03 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 06:57:02 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2ODv2M89864 for ; Tue, 24 Mar 2009 06:57:02 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903241357.n2ODv2M89864@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17864.1237903022.1@juniper.net> Date: Tue, 24 Mar 2009 06:57:02 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 24 Mar 2009 13:57:02.0574 (UTC) FILETIME=[688360E0:01C9AC88] Subject: [Idr] draft-chen-rfc4893bis-02.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 13:58:21 -0000 Folks, At the IDR WG meeting yesterday we had a very strong consensus for accepting draft-chen-rfc4893bis-02.txt as an IDR WG document. Given that, unless we have a fairly strong consensus against accepting this draft, the draft will be accepted as an IDR WG document. The deadline for comments is April 6, 2009. Yakov. From yakov@juniper.net Tue Mar 24 07:02:58 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E04A3A6CFE for ; Tue, 24 Mar 2009 07:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYWD1sz8S6NS for ; Tue, 24 Mar 2009 07:02:57 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 996F928C100 for ; Tue, 24 Mar 2009 07:02:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKScjoROPZqo1qugwFKMKnKlZZrMUYBu2G@postini.com; Tue, 24 Mar 2009 07:03:49 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Mar 2009 07:01:00 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 07:00:59 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 07:00:59 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 07:00:59 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2OE0xM92748 for ; Tue, 24 Mar 2009 07:00:59 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903241400.n2OE0xM92748@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18084.1237903259.1@juniper.net> Date: Tue, 24 Mar 2009 07:00:59 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 24 Mar 2009 14:00:59.0257 (UTC) FILETIME=[F5965690:01C9AC88] Subject: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 14:02:58 -0000 Folks, Just to add to the e-mail below, if anyone is aware of the IPR related to the draft, please follow the procedurs of rfc3979. Yakov. ------- Forwarded Message Date: Tue, 24 Mar 2009 06:53:45 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WG document Folks, At the IDR WG meeting yesterday we had a fairly strong consensus for accepting draft-rfernando-idr-link-bandwidth-00.txt as an IDR WG document. Given that, unless we have a fairly strong consensus on the mailing list against accepting this draft, the draft will be accepted as an IDR WG document. The deadline for comments is April 6, 2009. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message From yakov@juniper.net Tue Mar 24 07:04:09 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43BF63A68F7 for ; Tue, 24 Mar 2009 07:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-IDX6NDbHmj for ; Tue, 24 Mar 2009 07:04:08 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 754CB3A68DD for ; Tue, 24 Mar 2009 07:04:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKScjoi92mVoD5WjSCU9t/8Z5TOkT4sCKy@postini.com; Tue, 24 Mar 2009 07:05:00 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Mar 2009 07:01:56 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 07:01:56 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 07:01:56 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 07:01:55 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2OE1tM93559 for ; Tue, 24 Mar 2009 07:01:55 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903241401.n2OE1tM93559@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18112.1237903315.1@juniper.net> Date: Tue, 24 Mar 2009 07:01:55 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 24 Mar 2009 14:01:55.0428 (UTC) FILETIME=[17115A40:01C9AC89] Subject: [Idr] draft-scudder-idr-optional-transitive-01.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 14:04:09 -0000 Folks, Just to add to the e-mail below, if anyone is aware of the IPR related to the draft, please follow the procedurs of rfc3979. Yakov. ------- Forwarded Message Date: Tue, 24 Mar 2009 06:55:19 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] draft-scudder-idr-optional-transitive-01.txt as IDR WG document Folks, At the IDR WG meeting yesterday we had a very strong consensus for accepting draft-scudder-idr-optional-transitive-01.txt as an IDR WG document. Given that, unless we have a fairly strong consensus against accepting this draft, the draft will be accepted as an IDR WG document. The deadline for comments is April 6, 2009. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message From yakov@juniper.net Tue Mar 24 07:05:32 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD1828C10B for ; Tue, 24 Mar 2009 07:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXokJP+MH20o for ; Tue, 24 Mar 2009 07:05:31 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id A2C9D3A6A2F for ; Tue, 24 Mar 2009 07:05:29 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKScjo3D2N0BV0S3y9PaZf/XuYzSiVhEVv@postini.com; Tue, 24 Mar 2009 07:06:21 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Mar 2009 07:03:27 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 07:03:27 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 07:03:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 07:03:26 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2OE3QM94546 for ; Tue, 24 Mar 2009 07:03:26 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903241403.n2OE3QM94546@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18310.1237903406.1@juniper.net> Date: Tue, 24 Mar 2009 07:03:26 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 24 Mar 2009 14:03:26.0833 (UTC) FILETIME=[4D8CA610:01C9AC89] Subject: [Idr] draft-chen-rfc4893bis-02.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 14:05:32 -0000 Folks, Just to add to the e-mail below, if anyone is aware of the IPR related to the draft, please follow the procedurs of rfc3979. Yakov. ------- Forwarded Message Date: Tue, 24 Mar 2009 06:57:02 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] draft-chen-rfc4893bis-02.txt as IDR WG document Folks, At the IDR WG meeting yesterday we had a very strong consensus for accepting draft-chen-rfc4893bis-02.txt as an IDR WG document. Given that, unless we have a fairly strong consensus against accepting this draft, the draft will be accepted as an IDR WG document. The deadline for comments is April 6, 2009. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message From robert@raszuk.net Tue Mar 24 09:00:51 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EEB83A6A36 for ; Tue, 24 Mar 2009 09:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kfq1f6fXbKDL for ; Tue, 24 Mar 2009 09:00:50 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id D65E23A6857 for ; Tue, 24 Mar 2009 09:00:49 -0700 (PDT) Received: (qmail 5970 invoked by uid 399); 24 Mar 2009 16:01:39 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.242.169) by mail37.opentransfer.com with SMTP; 24 Mar 2009 16:01:39 -0000 Message-ID: <49C903E0.4070604@raszuk.net> Date: Tue, 24 Mar 2009 09:01:36 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: idr , "SCHOLL, TOM (ATTLABS)" , "John G. Scudder" Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:00:51 -0000 Tom, John and all, The presented draft demonstrates the need for more automation as well as more signaling between providers. While I am always in support of more automation let me point out number of issues with the proposed approach and suggest an alternative solution. First let's focus on the goal of the proposal. As I understand it and as it is spelled out quite clearly in the draft this is to inform respective administrator of the peering side about BGP events either planned (maintenance) or unplanned threshold based (example maximum prefix, applied dampening etc). It is also to automate existing fully manual way of critical or less critical bgp information distribution between peers. So the flow of the events is as follows: NOC_A -> ISP_A @ ASBR_A == EBGP == ASBR_B @ ISP_B -> NOC_B Planned events: --------------- * Operator A is generating a message at the CLI to a peer or group of EBGP peers * Message get's propagates via EBGP sessions * ASBR_B receives the message and it logs it to a syslog/local log file * Automated daemon parses the syslog or local log file, filters the message and provided it understands it sends to NOC_B In unplanned threshold based events the only difference is that this is not NOC_A but ASBR_A generating the msg. Issues: ------- * The proposed mechanism should be per SAFI. For one this is due to the reason that each SAFI may have it's own set of configured thresholds. For the second is that operational groups responsible for different network services are very often a separate groups of people. One could embed the info in the text itself, but it must be standardized so the parsing can be automated. * Parsing is an issue on the receiving side. Imagine the case how efficient and doable this solution is considering that your ASBR may be peering to 4000 up/down-stream peers as pointed out by Vijay. Each of those 4000 peers would first need to be able to support such parsing, understand to notify it's own administrator or NOC. * The proposed solution is very difficult deployment wise as both peering sides must support the functionality. * The most important issue I see with this approach in general is that enhancing protocol for new functionality is fine as long as both sides are educated how to use the information. Also it is fine as long as this is really necessary and any other solution would be either too difficult or impossible. As pointed out yesterday by Keyur Patel or for that matter by Pedro Marques when in July 2002 INFORM draft was discussed we are in no position to automate all possible actions on the receiver of such warning. This is the other side's operator which can in turn make some decisions. (Note that for the reload itself there are other proposals for example one by Bruno - on how to make it graceful). Suggested alternative: ---------------------- So what I would propose instead .... * To simplify the solution as well as avoid the must for protocol changes to make it working. There is one protocol enhancement I will propose instead which could be just an optimization ie solution can work without it. * To use automated out of band email based notification directly targeting corresponding NOC or admin of the peer, but auto generated from the router itself * To optionally allow for auto-receive of the per SAFI remote peer's admin/noc email address where the advisory messages should be send to Coming back to our original diagram: ___________________________________ | | ^ v NOC_A -> ISP_A @ ASBR_A == EBGP == ASBR_B @ ISP_B -> NOC_B Planned events: --------------- * NOC is performing some critical action on ASBR_A which triggers auto-generating a message at the CLI to a peers which are enabled for such notification * Operator at NOC_A does not need to worry to whom to send such message * Message get's propagates out of band directly to the most interested parties at the peering point (It could be usually a mailer alias of NOC engineers). Done ! * There is no need to maintain any parsing of syslog at the border ASBRs. In unplanned threshold based events the only difference is that this is not NOC_A's operator but ASBR_A generating the msg itself. Examples of planned messages/warnings: # router reload # peer hard clear Examples of unplanned threshold based messages: # prefix-limit reaching X% # dampening applied or about to be applied on prefix Z etc... What is required to support the above: -------------------------------------- * The implementation could be enhanced to allow to configure in the cli local admin_A@domain_isp_a as well as per peer/safi admin_B@domain_isp_b * The implementation should allow to pipe any delayed reload or clear command via a notifier function * For threshold based events today's implementation I am familiar with already have support for handling dynamic events (event scripts or embedded event manager) which could easily be instructed to do so and auto generate proper email notification msg. *OPTIONAL* To allow for dynamic update of such peer's email address we could indeed have an optional BGP capability just exchanged at the session establishment which would allow for dynamic per SAFI update of such email address fields on the peering side. But there is no need for any new BGP message type. Benefits summary of the alternative suggestion: ----------------------------------------------- * No need to modify BGP protocol (only if at all as an option we would see as a useful thing) * Deployable today via already existing operating systems * Works well for both planned maintenance or threshold based event driven notifications * Easy to enhance for more friendly operator's use via few cli changes * Follows other standard industry practices where for example unix hosts or good firewalls have such admin email configurable already ... why router's don't ? * Can be easily extended via the very same mechanism to other protocols .. not only BGP (Think about dynamic caching distribution protocol across admin boundaries) * Source NOC already has an option to also receive the auto-generated email confirmation as opposed to search syslog to find if, when and where such BGP embedded msg has been send out. Failure in receiver address is also automatically recognized. * No need to modify and parse anything at the potential 1000s of peers. Cheers, R. From robert@raszuk.net Tue Mar 24 09:13:42 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA68D3A6D37 for ; Tue, 24 Mar 2009 09:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+FgfmlN9Xx0 for ; Tue, 24 Mar 2009 09:13:42 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id DD5783A6D36 for ; Tue, 24 Mar 2009 09:13:41 -0700 (PDT) Received: (qmail 19142 invoked by uid 399); 24 Mar 2009 16:14:32 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.242.169) by mail37.opentransfer.com with SMTP; 24 Mar 2009 16:14:32 -0000 Message-ID: <49C906E6.9030904@raszuk.net> Date: Tue, 24 Mar 2009 09:14:30 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: idr Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:13:42 -0000 All, I would like to support the suggestion made yesterday by Enke Chen, Keyur Patel and Danny which suggested to make a good analysis for using MED + Cost Community which are an already existing tools to achieve the same functionality as the draft proposed via a definition of a new AIGP attribute. In fact the problem described in the draft is a very good example where practical problem can be solved using the above two solutions combined together. It can be a very good motivation for restarting work on cost community itself which were last posted draft-retana-bgp-custom-decision-00. There are apparently practical cases which this draft has a potential to solve and IMHO there is a saving to implement something once and then reuse for various applications as opposed to implementing separate attributes which would at the end result in more burden to BGP and deployment difficulties. Cheers, R. From Dimitri.Papadimitriou@alcatel-lucent.be Tue Mar 24 10:32:26 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C0128C1E5 for ; Tue, 24 Mar 2009 10:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+qvFUVKZNmn for ; Tue, 24 Mar 2009 10:32:25 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 9023828C1F8 for ; Tue, 24 Mar 2009 10:32:25 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2OHXFKM029035; Tue, 24 Mar 2009 18:33:15 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 18:33:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 18:33:24 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801F45603@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <200903241400.n2OE0xM92748@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WG document Thread-Index: AcmsiWe7S/jJkEhqTGSkB1MLz3BMbAAGjIag References: <200903241400.n2OE0xM92748@magenta.juniper.net> From: "PAPADIMITRIOU Dimitri" To: "Yakov Rekhter" , X-OriginalArrivalTime: 24 Mar 2009 17:33:14.0930 (UTC) FILETIME=[9CA3D120:01C9ACA6] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:32:26 -0000 Yakov: The Link Bandwidth Community used to be part of the BGP Extended Communities Attribute document (now RFC4360) until it was removed in v09 after review. At that it was stated that in order to perform BW-proportional BGP load-balancing, BGP multipath load balancing should be first documented. Isn't this condition still valid in the present case and the corr.mechanisms to be documented beyond limited deployment consideration part of Section 3? Thanks, -dimitri. > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Yakov Rekhter > Sent: Tuesday, March 24, 2009 3:01 PM > To: idr@ietf.org > Subject: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as=20 > IDR WG document >=20 > Folks, >=20 > Just to add to the e-mail below, if anyone is aware of the IPR > related to the draft, please follow the procedurs of rfc3979. >=20 > Yakov. > ------- Forwarded Message >=20 > Date: Tue, 24 Mar 2009 06:53:45 -0700 > From: Yakov Rekhter > To: idr@ietf.org > Subject: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as=20 > IDR WG document >=20 > Folks, >=20 > At the IDR WG meeting yesterday we had a fairly strong consensus > for accepting draft-rfernando-idr-link-bandwidth-00.txt as an IDR > WG document. Given that, unless we have a fairly strong consensus > on the mailing list against accepting this draft, the draft will > be accepted as an IDR WG document. The deadline for comments is > April 6, 2009. >=20 > Yakov. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From pmohapat@cisco.com Tue Mar 24 10:49:19 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B4728C31B for ; Tue, 24 Mar 2009 10:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjxIGNnx-240 for ; Tue, 24 Mar 2009 10:49:18 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 220EE28C320 for ; Tue, 24 Mar 2009 10:49:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,413,1233532800"; d="scan'208";a="145966706" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 24 Mar 2009 17:49:53 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2OHnr4F005157; Tue, 24 Mar 2009 10:49:53 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n2OHnrq8018417; Tue, 24 Mar 2009 17:49:53 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 10:49:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 10:49:51 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408EB8472@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49C906E6.9030904@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00 Thread-Index: Acmsm7L3MGVe+K30S6urNqBjcuHlagABoHGw References: <49C906E6.9030904@raszuk.net> From: "Pradosh Mohapatra (pmohapat)" To: , "idr" X-OriginalArrivalTime: 24 Mar 2009 17:49:53.0108 (UTC) FILETIME=[EF99B140:01C9ACA8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1568; t=1237916993; x=1238780993; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[Idr]=20draft-rosen-idr-aigp-00 |Sender:=20; bh=zNc9Xb8dgsrLRfnSd6QrQVeLxKFhNhgFIq4HrObJt04=; b=cBmjFGVC/mk+nIMyNgjjSCTnHv05AWmth+FpildpPITYcfUGkJfn91VAc8 606XxFUHHkrr/7GlaOBdcLvFC/fn9FVBe3ec2peF+oEPN3LBVeU30sWS2JB0 JSY2/L6LSJ; Authentication-Results: sj-dkim-3; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:49:19 -0000 Hi Robert, Thanks for the comments. Inline: | I would like to support the suggestion made yesterday by Enke=20 | Chen, Keyur Patel and Danny which suggested to make a good=20 | analysis for using MED + Cost Community which are an already=20 | existing tools to achieve the same functionality as the draft=20 | proposed via a definition of a new AIGP attribute. Here are the replies I made during the WG discussion for these questions: 1) MED alone is not a good tool since the MED comparison step is after AS_PATH length comparison. 2) Cost community is an extended community which is optional transitive. We want to make the attribute non- transitive to restrict its scope of propagation. - Pradosh |=20 | In fact the problem described in the draft is a very good=20 | example where practical problem can be solved using the above=20 | two solutions combined together. |=20 | It can be a very good motivation for restarting work on cost=20 | community itself which were last posted=20 | draft-retana-bgp-custom-decision-00. There are apparently=20 | practical cases which this draft has a potential to solve and=20 | IMHO there is a saving to implement something once and then=20 | reuse for various applications as opposed to implementing=20 | separate attributes which would at the end result in more=20 | burden to BGP and deployment difficulties. |=20 | Cheers, | R. |=20 | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr |=20 From robert@raszuk.net Tue Mar 24 10:54:42 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341B83A68E0 for ; Tue, 24 Mar 2009 10:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoEytNGu3V95 for ; Tue, 24 Mar 2009 10:54:41 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 2053528C114 for ; Tue, 24 Mar 2009 10:54:41 -0700 (PDT) Received: (qmail 14585 invoked by uid 399); 24 Mar 2009 17:55:32 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.242.169) by mail37.opentransfer.com with SMTP; 24 Mar 2009 17:55:32 -0000 Message-ID: <49C91E91.3020403@raszuk.net> Date: Tue, 24 Mar 2009 10:55:29 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Pradosh Mohapatra (pmohapat)" References: <49C906E6.9030904@raszuk.net> <04CAD96D4C5A3D48B1919248A8FE0D5408EB8472@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5408EB8472@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:54:42 -0000 Hi Pradosh, > 1) MED alone is not a good tool since the MED comparison step > is after AS_PATH length comparison. Correct. That is why I proposed to use it along with cost communities. > 2) Cost community is an extended community which is optional > transitive. We want to make the attribute non- > transitive to restrict its scope of propagation. Transitiveness should be discussed in the scope. Ext community attribute is transitive within the domain. Inter-domain high-order type field decides if this should be transitive or not at the AS boundary. Cost community is not transitive. Exactly as required :). The BGP Cost Community The BGP Cost Community is an Opaque Extended Community [EXT_COMM] defined as follows: Type Field: The value of the high-order octet of the extended Type Field is 0x43, which indicates it is non-transitive. The value of the low-order octet of the extended type field for this community is TBD. Cheers, R. > Hi Robert, > > Thanks for the comments. Inline: > > | I would like to support the suggestion made yesterday by Enke > | Chen, Keyur Patel and Danny which suggested to make a good > | analysis for using MED + Cost Community which are an already > | existing tools to achieve the same functionality as the draft > | proposed via a definition of a new AIGP attribute. > > Here are the replies I made during the WG discussion for these > questions: > > 1) MED alone is not a good tool since the MED comparison step > is after AS_PATH length comparison. > 2) Cost community is an extended community which is optional > transitive. We want to make the attribute non- > transitive to restrict its scope of propagation. > > - Pradosh > > | > | In fact the problem described in the draft is a very good > | example where practical problem can be solved using the above > | two solutions combined together. > | > | It can be a very good motivation for restarting work on cost > | community itself which were last posted > | draft-retana-bgp-custom-decision-00. There are apparently > | practical cases which this draft has a potential to solve and > | IMHO there is a saving to implement something once and then > | reuse for various applications as opposed to implementing > | separate attributes which would at the end result in more > | burden to BGP and deployment difficulties. > | > | Cheers, > | R. > | > | _______________________________________________ > | Idr mailing list > | Idr@ietf.org > | https://www.ietf.org/mailman/listinfo/idr > | > > From pmohapat@cisco.com Tue Mar 24 11:04:39 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE8028C31C for ; Tue, 24 Mar 2009 11:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU2o1rEdf163 for ; Tue, 24 Mar 2009 11:04:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AF94C28C31A for ; Tue, 24 Mar 2009 11:04:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,413,1233532800"; d="scan'208";a="273301172" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Mar 2009 18:05:25 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2OI5PRN006113; Tue, 24 Mar 2009 11:05:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2OI5P7i009288; Tue, 24 Mar 2009 18:05:25 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 11:05:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 11:05:22 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408EB8496@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49C91E91.3020403@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00 Thread-Index: AcmsqbqvYpYUVk1wSeqnfyHaf/YrkAAAP3cA References: <49C906E6.9030904@raszuk.net> <04CAD96D4C5A3D48B1919248A8FE0D5408EB8472@xmb-sjc-215.amer.cisco.com> <49C91E91.3020403@raszuk.net> From: "Pradosh Mohapatra (pmohapat)" To: X-OriginalArrivalTime: 24 Mar 2009 18:05:24.0915 (UTC) FILETIME=[1B002830:01C9ACAB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1325; t=1237917925; x=1238781925; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[Idr]=20draft-rosen-idr-aigp-00 |Sender:=20; bh=5coMqMy6K13EVPNW5SLKwrP+Ugs0kPSVzFeO/IzCw+A=; b=N2YIzsdTrCcaWwu8rAxUi3Md2YMQbqy6J4lzuKLVnZTxm8l4/y49sjChch v7DX0eGVK8nePmKI3vhbfdq0D5LzPJobW223ND+OP+lSfteJKniXwi4e3KQS 3b48foBxaW; Authentication-Results: sj-dkim-4; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: idr Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:04:39 -0000 | > 1) MED alone is not a good tool since the MED comparison step | > is after AS_PATH length comparison. |=20 | Correct. That is why I proposed to use it along with cost communities. |=20 | > 2) Cost community is an extended community which is optional | > transitive. We want to make the attribute non- | > transitive to restrict its scope of propagation. |=20 | Transitiveness should be discussed in the scope. Ext=20 | community attribute is transitive within the domain.=20 | Inter-domain high-order type field decides if this should be=20 | transitive or not at the AS boundary. |=20 | Cost community is not transitive. |=20 | Exactly as required :). |=20 | The BGP Cost Community |=20 | The BGP Cost Community is an Opaque Extended Community [EXT_COMM] | defined as follows: |=20 | Type Field: |=20 | The value of the high-order octet of the extended=20 | Type Field is | 0x43, which indicates it is non-transitive. The value of the | low-order octet of the extended type field for this=20 | community | is TBD. Understood. The extended community is an optional transitive attribute. What if a router doesn't understand extended community at all? It would pass along the cost community, wouldn't it? - Pradosh From robert@raszuk.net Tue Mar 24 11:12:41 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC7B28C329 for ; Tue, 24 Mar 2009 11:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nLfxCMyF9Zn for ; Tue, 24 Mar 2009 11:12:40 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id ADECD28C325 for ; Tue, 24 Mar 2009 11:12:40 -0700 (PDT) Received: (qmail 31518 invoked by uid 399); 24 Mar 2009 18:13:31 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.242.169) by mail37.opentransfer.com with SMTP; 24 Mar 2009 18:13:31 -0000 Message-ID: <49C922C9.6070200@raszuk.net> Date: Tue, 24 Mar 2009 11:13:29 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Pradosh Mohapatra (pmohapat)" References: <49C906E6.9030904@raszuk.net> <04CAD96D4C5A3D48B1919248A8FE0D5408EB8472@xmb-sjc-215.amer.cisco.com> <49C91E91.3020403@raszuk.net> <04CAD96D4C5A3D48B1919248A8FE0D5408EB8496@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5408EB8496@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:12:41 -0000 Hi Pradosh, > Understood. The extended community is an optional transitive > attribute. What if a router doesn't understand extended community at > all? It would pass along the cost community, wouldn't it? Let's be practical .... Is there any router on the market, used in the production at the AS boundary as an ASBR which does not understand ext communities ? In any case to assure that using cost community would be safe the function under discussion will not be used by default. So in any transit AS it would just propagate. If you have to upgrade your ASBR to understand AIGP new attribute you may as well upgrade it to the image which also understands ext communities :). Then you are 100% safe. Cheers, R. > | > 1) MED alone is not a good tool since the MED comparison step > | > is after AS_PATH length comparison. > | > | Correct. That is why I proposed to use it along with cost communities. > | > | > 2) Cost community is an extended community which is optional > | > transitive. We want to make the attribute non- > | > transitive to restrict its scope of propagation. > | > | Transitiveness should be discussed in the scope. Ext > | community attribute is transitive within the domain. > | Inter-domain high-order type field decides if this should be > | transitive or not at the AS boundary. > | > | Cost community is not transitive. > | > | Exactly as required :). > | > | The BGP Cost Community > | > | The BGP Cost Community is an Opaque Extended Community [EXT_COMM] > | defined as follows: > | > | Type Field: > | > | The value of the high-order octet of the extended > | Type Field is > | 0x43, which indicates it is non-transitive. The value of the > | low-order octet of the extended type field for this > | community > | is TBD. > > Understood. The extended community is an optional transitive attribute. > What if a router doesn't understand extended community at all? It would > pass along the cost community, wouldn't it? > > - Pradosh > > From ras@gerbil.cluepon.net Tue Mar 24 11:57:27 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB36428C348 for ; Tue, 24 Mar 2009 11:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0TcD-gos2KH for ; Tue, 24 Mar 2009 11:57:26 -0700 (PDT) Received: from gerbil.cluepon.net (e-gerbil.net [69.31.1.2]) by core3.amsl.com (Postfix) with ESMTP id 2EBED28C342 for ; Tue, 24 Mar 2009 11:57:26 -0700 (PDT) Received: from gerbil.cluepon.net (ras@localhost [127.0.0.1]) by gerbil.cluepon.net (8.14.3/8.14.3) with ESMTP id n2OIwF4j085564; Tue, 24 Mar 2009 13:58:15 -0500 (CDT) (envelope-from ras@gerbil.cluepon.net) Received: (from ras@localhost) by gerbil.cluepon.net (8.14.3/8.14.3/Submit) id n2OIwEXn085563; Tue, 24 Mar 2009 13:58:14 -0500 (CDT) (envelope-from ras) Date: Tue, 24 Mar 2009 13:58:14 -0500 From: Richard A Steenbergen To: Robert Raszuk Message-ID: <20090324185814.GF51443@gerbil.cluepon.net> References: <49C903E0.4070604@raszuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C903E0.4070604@raszuk.net> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "SCHOLL, TOM \(ATTLABS\)" , idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:57:27 -0000 On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote: > > * Parsing is an issue on the receiving side. Imagine the case how > efficient and doable this solution is considering that your ASBR may be > peering to 4000 up/down-stream peers as pointed out by Vijay. Each of > those 4000 peers would first need to be able to support such parsing, > understand to notify it's own administrator or NOC. One thing to keep in mind is that for every Google sized network on the Internet, there are thousands of smaller sized networks with very different needs. I'm not arguing that it doesn't make sense for Google to try and design a system which keeps humans off the routers, but for the vast majority of the world when something goes down there is a human who logs into a router and does a "show log" to figure out why. In fact, one could argue that the vast majority of Google's peers operate this way, therefore Google could still see significant advantages when sending messages to other networks, even if they don't when receiving messages from them. Plus, this is the kind of thing that could easily be initiated via snmp or netconf, and picked up via an snmp trap or other monitoring tool which already exist. > * The proposed solution is very difficult deployment wise as both > peering sides must support the functionality. I don't see the difficulty. The best case is that the extra level of communication helps operators run their networks, the worst case is that it is unsupported or ignored by the other side because they aren't expecting it. This is no worse off than we are today. I don't think anyone is under any delusions that this will ever completely replace out of band communications, and certainly not from day 1. That said, it seems a little odd to argue against standardizing and implementing a tool which currently doesn't help you because it hasn't been standardized and implemented. Over time more and more devices will be able to support it, as networks upgrade their router code. Until then, it causes no harm, generates no additional work-load, and the sending party will know if the other side supports the advisory capability and is even capable of receiving the message. > As pointed out yesterday by Keyur Patel or for that matter by Pedro > Marques when in July 2002 INFORM draft was discussed we are in no > position to automate all possible actions on the receiver of such > warning. This is the other side's operator which can in turn make some > decisions. (Note that for the reload itself there are other proposals > for example one by Bruno - on how to make it graceful). I was actually afraid that this might be the reaction when I saw the example use of signaling the approach of a max-prefix limit. Clearly a structured message such as the INFORM draft is a better way to go about signaling something like this, but I think the point being made is that an advisory message would at least provide a possible mechanism for communicating this where today there is none. The ability to send a free-form message has the advantage of being able to adapt to any situation that operators might find, instead of requiring the IETF to think up every possible message type beforehand. > * To simplify the solution as well as avoid the must for protocol > changes to make it working. There is one protocol enhancement I will > propose instead which could be just an optimization ie solution can work > without it. This feature seems to trivial and easy to implement that I have a hard time thinking of it as a true protocol change. Think of it as an extremely simple method of interprovider communication which just happens to piggyback on the existing BGP protocol for no other reason than that BGP is the only real interprovider protocol to piggyback on. > * To use automated out of band email based notification directly > targeting corresponding NOC or admin of the peer, but auto generated > from the router itself > > * To optionally allow for auto-receive of the per SAFI remote peer's > admin/noc email address where the advisory messages should be send to > > Coming back to our original diagram: > > ___________________________________ > | | > ^ v > NOC_A -> ISP_A @ ASBR_A == EBGP == ASBR_B @ ISP_B -> NOC_B One significant advantage to in-band signaling over BGP is the built in authentication mechanism. By its very nature it is impossible to send to or receive from someone who is not a directly connected and configured BGP peer. The existence of the BGP session itself proves both the direct relationship, and simply and securely associates the message with a specific peer and BGP session. It also serves to get the message delivered directly to the people who are most interested in seeing it, the engineering/operations staff on the other side of the connection who have access to the router in question. To implement this via an out-of-band signaling method, you would need yet another layer 8 signaling to negotiate NOC contact information and an authentication mechanism, which must then be kept up to date using more layer 8 signaling. This is essentially the system of inter-network communication we use today, it just takes the form of e-mails, telephone numbers, and the occasional post to operators mailing lists trying to negotiate a signaling path to someone clueful. You would also need to deliver the out of band message via some other mechanism such as the Internet, which one could consider less secure than delivering it via the existing direct connection between the two routers in question. This might also require a full table, which is intentionally not configured on many border routers as an anti-traffic injection mechanism. I believe most large networks with a complex management structure already have existing (plus working and vetted) mechanisms for collecting data coming in from distributed routers and feeding it back to centralized monitoring systems, so this would be a natural extension of that functionality. Adding another out of band communications infrastructure seems significantly more complex, and significantly less likely to be implementable in the near future. As any network operator who lived through the great BGP MD5 scare is well aware, communication with third party networks is difficult at best, and painful or impossible at worst. Consider for example the process that goes on every time a BGP session flaps. NOC_A receives a monitoring alert/trap about the session, then tries to determine if this is an event they were expecting (by checking for layer 8 communication such as e-mails on the subject), and if they can't find it they then initiate communication with NOC_B via a mechanism like e-mail or telephone inquiring about the event. NOC_B then has to determine if this is an event they were expecting, by searching their own e-mails or maintenance calendars, or talking to their engineering/ops group. Anyone who has ever done maintenance on an exchange point router with a few hundred peers is well aware of the dozens of unnecessary e-mails or calls this will generate, even if a maintenance notification was sent out. This also does nothing to address the case of an emergency maintenance, such as an unscheduled but engineering initiated reload. > In unplanned threshold based events the only difference is that this is > not NOC_A's operator but ASBR_A generating the msg itself. > > Examples of planned messages/warnings: > > # router reload > # peer hard clear > > Examples of unplanned threshold based messages: > > # prefix-limit reaching X% > # dampening applied or about to be applied on prefix Z > etc... I agree that structured messages certainly have their place, and I agree that prefix-limit reaching/exceeded/etc is certainly best served by that type of message, but I don't think this replaces the benefits of a free-form text message. There are already notification messages for a peer hard clear, but they aren't capable of telling the other side WHY the session was cleared. This issue reaches beyond the world of protocol design, and plants itself firmly in the realm of the network operator community. Certainly every network operator I've talked to has all but jumped for joy at the prospect of having this functionality, and I'm certain we can find a few of them to state as much on this list. The only thing the IETF needs to do is provide the communication mechanism (which is fortunately extremely simple to do), and then leave the network operators to use the tool as they see fit. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From Ted.A.Seely@sprint.com Tue Mar 24 12:43:14 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F55B28C157 for ; Tue, 24 Mar 2009 12:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g0ARqOJvKDw for ; Tue, 24 Mar 2009 12:43:12 -0700 (PDT) Received: from WA4EHSOBE003.bigfish.com (wa4ehsobe003.messaging.microsoft.com [216.32.181.13]) by core3.amsl.com (Postfix) with ESMTP id BB3AC28C146 for ; Tue, 24 Mar 2009 12:43:10 -0700 (PDT) Received: from mail159-wa4-R.bigfish.com (10.8.14.245) by WA4EHSOBE003.bigfish.com (10.8.40.23) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Mar 2009 19:44:01 +0000 Received: from mail159-wa4 (localhost.localdomain [127.0.0.1]) by mail159-wa4-R.bigfish.com (Postfix) with ESMTP id CFAC36702ED; Tue, 24 Mar 2009 19:44:00 +0000 (UTC) X-BigFish: VS-41(zz1432R9cdeh98dR1805M936fK19c2k3646i8c8aizz1202hzz1033ILz2fh6bh43j61h) X-Spam-TCS-SCL: 0:0 X-FB-SS: 5,5, Received: by mail159-wa4 (MessageSwitch) id 1237923832605483_16271; Tue, 24 Mar 2009 19:43:52 +0000 (UCT) Received: from plss1400.corp.sprint.com (unknown [144.230.162.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail159-wa4.bigfish.com (Postfix) with ESMTP id C0ACD15880B9; Tue, 24 Mar 2009 19:43:48 +0000 (UTC) Received: from plswh04a.ad.sprint.com (plswh04a.corp.sprint.com [144.226.251.24]) by plss1400.corp.sprint.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n2OJhiLG003719; Tue, 24 Mar 2009 14:43:47 -0500 (CDT) Received: from PDAWM02C.ad.sprint.com ([144.226.111.25]) by plswh04a.ad.sprint.com ([2002:90e2:fb18::90e2:fb18]) with mapi; Tue, 24 Mar 2009 14:43:25 -0500 From: "Seely, Ted A [CTO]" To: Richard A Steenbergen , Robert Raszuk Date: Tue, 24 Mar 2009 14:43:22 -0500 Thread-Topic: [Idr] draft-scholl-idr-advisory-00 Thread-Index: AcmsspednKueYrwWQuWfbdJ/+ecpuwABjJnx Message-ID: In-Reply-To: <20090324185814.GF51443@gerbil.cluepon.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5EEB01BDBD9tedaseelysprintcom_" MIME-Version: 1.0 Cc: "SCHOLL, TOM \(ATTLABS\)" , idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:43:14 -0000 --_000_C5EEB01BDBD9tedaseelysprintcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 ________________________________ From: Richard A Steenbergen Date: Tue, 24 Mar 2009 13:58:14 -0500 To: Robert Raszuk Cc: "SCHOLL, TOM (ATTLABS)" , idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote: > > * Parsing is an issue on the receiving side. Imagine the case how > efficient and doable this solution is considering that your ASBR may be > peering to 4000 up/down-stream peers as pointed out by Vijay. Each of > those 4000 peers would first need to be able to support such parsing, > understand to notify it's own administrator or NOC. One thing to keep in mind is that for every Google sized network on the Internet, there are thousands of smaller sized networks with very different needs. I'm not arguing that it doesn't make sense for Google to try and design a system which keeps humans off the routers, but for the vast majority of the world when something goes down there is a human who logs into a router and does a "show log" to figure out why. In fact, one could argue that the vast majority of Google's peers operate this way, therefore Google could still see significant advantages when sending messages to other networks, even if they don't when receiving messages from them. Plus, this is the kind of thing that could easily be initiated via snmp or netconf, and picked up via an snmp trap or other monitoring tool which already exist. > * The proposed solution is very difficult deployment wise as both > peering sides must support the functionality. I don't see the difficulty. The best case is that the extra level of communication helps operators run their networks, the worst case is that it is unsupported or ignored by the other side because they aren't expecting it. This is no worse off than we are today. I don't think anyone is under any delusions that this will ever completely replace out of band communications, and certainly not from day 1. That said, it seems a little odd to argue against standardizing and implementing a tool which currently doesn't help you because it hasn't been standardized and implemented. Over time more and more devices will be able to support it, as networks upgrade their router code. Until then, it causes no harm, generates no additional work-load, and the sending party will know if the other side supports the advisory capability and is even capable of receiving the message. > As pointed out yesterday by Keyur Patel or for that matter by Pedro > Marques when in July 2002 INFORM draft was discussed we are in no > position to automate all possible actions on the receiver of such > warning. This is the other side's operator which can in turn make some > decisions. (Note that for the reload itself there are other proposals > for example one by Bruno - on how to make it graceful). I was actually afraid that this might be the reaction when I saw the example use of signaling the approach of a max-prefix limit. Clearly a structured message such as the INFORM draft is a better way to go about signaling something like this, but I think the point being made is that an advisory message would at least provide a possible mechanism for communicating this where today there is none. The ability to send a free-form message has the advantage of being able to adapt to any situation that operators might find, instead of requiring the IETF to think up every possible message type beforehand. > * To simplify the solution as well as avoid the must for protocol > changes to make it working. There is one protocol enhancement I will > propose instead which could be just an optimization ie solution can work > without it. This feature seems to trivial and easy to implement that I have a hard time thinking of it as a true protocol change. Think of it as an extremely simple method of interprovider communication which just happens to piggyback on the existing BGP protocol for no other reason than that BGP is the only real interprovider protocol to piggyback on. > * To use automated out of band email based notification directly > targeting corresponding NOC or admin of the peer, but auto generated > from the router itself > > * To optionally allow for auto-receive of the per SAFI remote peer's > admin/noc email address where the advisory messages should be send to > > Coming back to our original diagram: > > ___________________________________ > | | > ^ v > NOC_A -> ISP_A @ ASBR_A =3D=3D EBGP =3D=3D ASBR_B @ ISP_B -> NOC_B One significant advantage to in-band signaling over BGP is the built in authentication mechanism. By its very nature it is impossible to send to or receive from someone who is not a directly connected and configured BGP peer. The existence of the BGP session itself proves both the direct relationship, and simply and securely associates the message with a specific peer and BGP session. It also serves to get the message delivered directly to the people who are most interested in seeing it, the engineering/operations staff on the other side of the connection who have access to the router in question. To implement this via an out-of-band signaling method, you would need yet another layer 8 signaling to negotiate NOC contact information and an authentication mechanism, which must then be kept up to date using more layer 8 signaling. This is essentially the system of inter-network communication we use today, it just takes the form of e-mails, telephone numbers, and the occasional post to operators mailing lists trying to negotiate a signaling path to someone clueful. You would also need to deliver the out of band message via some other mechanism such as the Internet, which one could consider less secure than delivering it via the existing direct connection between the two routers in question. This might also require a full table, which is intentionally not configured on many border routers as an anti-traffic injection mechanism. I believe most large networks with a complex management structure already have existing (plus working and vetted) mechanisms for collecting data coming in from distributed routers and feeding it back to centralized monitoring systems, so this would be a natural extension of that functionality. Adding another out of band communications infrastructure seems significantly more complex, and significantly less likely to be implementable in the near future. As any network operator who lived through the great BGP MD5 scare is well aware, communication with third party networks is difficult at best, and painful or impossible at worst. Consider for example the process that goes on every time a BGP session flaps. NOC_A receives a monitoring alert/trap about the session, then tries to determine if this is an event they were expecting (by checking for layer 8 communication such as e-mails on the subject), and if they can't find it they then initiate communication with NOC_B via a mechanism like e-mail or telephone inquiring about the event. NOC_B then has to determine if this is an event they were expecting, by searching their own e-mails or maintenance calendars, or talking to their engineering/ops group. Anyone who has ever done maintenance on an exchange point router with a few hundred peers is well aware of the dozens of unnecessary e-mails or calls this will generate, even if a maintenance notification was sent out. This also does nothing to address the case of an emergency maintenance, such as an unscheduled but engineering initiated reload. > In unplanned threshold based events the only difference is that this is > not NOC_A's operator but ASBR_A generating the msg itself. > > Examples of planned messages/warnings: > > # router reload > # peer hard clear > > Examples of unplanned threshold based messages: > > # prefix-limit reaching X% > # dampening applied or about to be applied on prefix Z > etc... I agree that structured messages certainly have their place, and I agree that prefix-limit reaching/exceeded/etc is certainly best served by that type of message, but I don't think this replaces the benefits of a free-form text message. There are already notification messages for a peer hard clear, but they aren't capable of telling the other side WHY the session was cleared. This issue reaches beyond the world of protocol design, and plants itself firmly in the realm of the network operator community. Certainly every network operator I've talked to has all but jumped for joy at the prospect of having this functionality, and I'm certain we can find a few of them to state as much on this list. The only thing the IETF needs to do is provide the communication mechanism (which is fortunately extremely simple to do), and then leave the network operators to use the tool as they see fit. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ________________________________ This e-mail may contain Sprint Nextel Company proprietary information inten= ded for the sole use of the recipient(s). Any use by others is prohibited. = If you are not the intended recipient, please contact the sender and delete= all copies of the message. --_000_C5EEB01BDBD9tedaseelysprintcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Idr] draft-scholl-idr-advisory-00 +1


From: Richard A Steenbergen <ras@e-g= erbil.net>
Date: Tue, 24 Mar 2009 13:58:14 -0500
To: Robert Raszuk <robert@raszuk.ne= t>
Cc: "SCHOLL, TOM (ATTLABS)" <ts3127@att.com>, idr <idr@ietf.org&= gt;
Subject: Re: [Idr] draft-scholl-idr-advisory-00

On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote:
>
> * Parsing is an issue on the receiving side. Imagine the case how
> efficient and doable this solution is considering that your ASBR may b= e
> peering to 4000 up/down-stream peers as pointed out by Vijay. Each of<= br> > those 4000 peers would first need to be able to support such parsing,<= br> > understand to notify it's own administrator or NOC.

One thing to keep in mind is that for every Google sized network on the
Internet, there are thousands of smaller sized networks with very
different needs. I'm not arguing that it doesn't make sense for Google
to try and design a system which keeps humans off the routers, but for
the vast majority of the world when something goes down there is a human who logs into a router and does a "show log" to figure out why. I= n fact,
one could argue that the vast majority of Google's peers operate this
way, therefore Google could still see significant advantages when
sending messages to other networks, even if they don't when receiving
messages from them.

Plus, this is the kind of thing that could easily be initiated via snmp
or netconf, and picked up via an snmp trap or other monitoring tool
which already exist.

> * The proposed solution is very difficult deployment wise as both
> peering sides must support the functionality.

I don't see the difficulty. The best case is that the extra level of
communication helps operators run their networks, the worst case is that it is unsupported or ignored by the other side because they aren't
expecting it. This is no worse off than we are today. I don't think
anyone is under any delusions that this will ever completely replace out of band communications, and certainly not from day 1.

That said, it seems a little odd to argue against standardizing and
implementing a tool which currently doesn't help you because it hasn't
been standardized and implemented. Over time more and more devices will
be able to support it, as networks upgrade their router code. Until
then, it causes no harm, generates no additional work-load, and the
sending party will know if the other side supports the advisory
capability and is even capable of receiving the message.

> As pointed out yesterday by Keyur Patel or for that matter by Pedro > Marques when in July 2002 INFORM draft was discussed we are in no
> position to automate all possible actions on the receiver of such
> warning. This is the other side's operator which can in turn make some=
> decisions. (Note that for the reload itself there are other proposals<= br> > for example one by Bruno - on how to make it graceful).

I was actually afraid that this might be the reaction when I saw the
example use of signaling the approach of a max-prefix limit. Clearly a
structured message such as the INFORM draft is a better way to go about
signaling something like this, but I think the point being made is that
an advisory message would at least provide a possible mechanism for
communicating this where today there is none. The ability to send a
free-form message has the advantage of being able to adapt to any
situation that operators might find, instead of requiring the IETF to
think up every possible message type beforehand.

> * To simplify the solution as well as avoid the must for protocol
> changes to make it working. There is one protocol enhancement I will > propose instead which could be just an optimization ie solution can wo= rk
> without it.

This feature seems to trivial and easy to implement that I have a hard
time thinking of it as a true protocol change. Think of it as an
extremely simple method of interprovider communication which just
happens to piggyback on the existing BGP protocol for no other reason
than that BGP is the only real interprovider protocol to piggyback on.

> * To use automated out of band email based notification directly
> targeting corresponding NOC or admin of the peer, but auto generated > from the router itself
>
> * To optionally allow for auto-receive of the per SAFI remote peer's > admin/noc email address where the advisory messages should be send to<= br> >
> Coming back to our original diagram:
>
>            &nbs= p;       _______________________________= ____
>            &nbs= p;      |       = ;            &n= bsp;            = ;   |
>            &nbs= p;      ^       = ;            &n= bsp;            = ;   v
> NOC_A -> ISP_A @ ASBR_A =3D=3D EBGP =3D=3D ASBR_B @ ISP_B -> NOC= _B

One significant advantage to in-band signaling over BGP is the built in
authentication mechanism. By its very nature it is impossible to send to or receive from someone who is not a directly connected and configured
BGP peer. The existence of the BGP session itself proves both the direct relationship, and simply and securely associates the message with a
specific peer and BGP session. It also serves to get the message
delivered directly to the people who are most interested in seeing it,
the engineering/operations staff on the other side of the connection who have access to the router in question.

To implement this via an out-of-band signaling method, you would need
yet another layer 8 signaling to negotiate NOC contact information and
an authentication mechanism, which must then be kept up to date using
more layer 8 signaling. This is essentially the system of inter-network
communication we use today, it just takes the form of e-mails, telephone numbers, and the occasional post to operators mailing lists trying to
negotiate a signaling path to someone clueful. You would also need to
deliver the out of band message via some other mechanism such as the
Internet, which one could consider less secure than delivering it via
the existing direct connection between the two routers in question. This might also require a full table, which is intentionally not configured
on many border routers as an anti-traffic injection mechanism.

I believe most large networks with a complex management structure
already have existing (plus working and vetted) mechanisms for
collecting data coming in from distributed routers and feeding it back
to centralized monitoring systems, so this would be a natural extension
of that functionality. Adding another out of band communications
infrastructure seems significantly more complex, and significantly less
likely to be implementable in the near future.

As any network operator who lived through the great BGP MD5 scare is
well aware, communication with third party networks is difficult at
best, and painful or impossible at worst. Consider for example the
process that goes on every time a BGP session flaps. NOC_A receives a
monitoring alert/trap about the session, then tries to determine if this is an event they were expecting (by checking for layer 8 communication
such as e-mails on the subject), and if they can't find it they then
initiate communication with NOC_B via a mechanism like e-mail or
telephone inquiring about the event. NOC_B then has to determine if this is an event they were expecting, by searching their own e-mails or
maintenance calendars, or talking to their engineering/ops group. Anyone who has ever done maintenance on an exchange point router with a few
hundred peers is well aware of the dozens of unnecessary e-mails or
calls this will generate, even if a maintenance notification was sent
out. This also does nothing to address the case of an emergency
maintenance, such as an unscheduled but engineering initiated reload.

> In unplanned threshold based events the only difference is that this i= s
> not NOC_A's operator but ASBR_A generating the msg itself.
>
> Examples of planned messages/warnings:
>
> # router reload
> # peer hard clear
>
> Examples of unplanned threshold based messages:
>
> # prefix-limit reaching X%
> # dampening applied or about to be applied on prefix Z
> etc...

I agree that structured messages certainly have their place, and I agree that prefix-limit reaching/exceeded/etc is certainly best served by that type of message, but I don't think this replaces the benefits of a
free-form text message. There are already notification messages for a
peer hard clear, but they aren't capable of telling the other side WHY
the session was cleared.

This issue reaches beyond the world of protocol design, and plants
itself firmly in the realm of the network operator community. Certainly
every network operator I've talked to has all but jumped for joy at the
prospect of having this functionality, and I'm certain we can find a few of them to state as much on this list. The only thing the IETF needs to
do is provide the communication mechanism (which is fortunately
extremely simple to do), and then leave the network operators to use the tool as they see fit.

--
Richard A Steenbergen <ras@e-gerbil.net= >       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)<= br> _______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/= mailman/listinfo/idr



This e-mail may contain Spri= nt Nextel Company proprietary information intended for the sole use of the = recipient(s). Any use by others is prohibited. If you are not the intended = recipient, please contact the sender and delete all copies of the message.
 --_000_C5EEB01BDBD9tedaseelysprintcom_-- From mschmidt@equinix.com Tue Mar 24 13:01:22 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849A13A6B56 for ; Tue, 24 Mar 2009 13:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgKt-aVumWUq for ; Tue, 24 Mar 2009 13:01:20 -0700 (PDT) Received: from smtpobhost.equinix.net (smtpobhost.equinix.net [207.20.85.100]) by core3.amsl.com (Postfix) with ESMTP id BAD3228C164 for ; Tue, 24 Mar 2009 13:01:15 -0700 (PDT) Received: from glaciar.corp.equinix.com (mschmidt1-test.sv3.corp.equinix.com [172.22.28.245] (may be forged)) by prod107.corp.equinix.com (8.14.3/8.14.3) with ESMTP id n2OK1xgZ000367; Tue, 24 Mar 2009 13:01:59 -0700 (PDT) Received: from glaciar.corp.equinix.com (localhost [127.0.0.1]) by glaciar.corp.equinix.com (8.12.11/8.12.11) with ESMTP id n2OK1tW1000019; Tue, 24 Mar 2009 13:01:55 -0700 (PDT) Received: (from mschmidt@localhost) by glaciar.corp.equinix.com (8.12.11/8.12.11) id n2OK1rW1009749; Tue, 24 Mar 2009 13:01:53 -0700 (PDT) Date: Tue, 24 Mar 2009 13:01:52 -0700 From: Marcelo Schmidt To: Richard A Steenbergen Message-ID: <20090324200152.GA18430@equinix.com> References: <49C903E0.4070604@raszuk.net> <20090324185814.GF51443@gerbil.cluepon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <20090324185814.GF51443@gerbil.cluepon.net> User-Agent: Mutt/1.4.2.1i Cc: "SCHOLL, TOM \(ATTLABS\)" , idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:01:22 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable +1 On Tue, Mar 24, 2009 at 11:58:14AM -0700, Richard A Steenbergen wrote: >=20 > On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote: > > > > * Parsing is an issue on the receiving side. Imagine the case how > > efficient and doable this solution is considering that your ASBR may > be > > peering to 4000 up/down-stream peers as pointed out by Vijay. Each > of > > those 4000 peers would first need to be able to support such > parsing, > > understand to notify it's own administrator or NOC. > One thing to keep in mind is that for every Google sized network on > the > Internet, there are thousands of smaller sized networks with very > different needs. I'm not arguing that it doesn't make sense for Google > to try and design a system which keeps humans off the routers, but for > the vast majority of the world when something goes down there is a > human > who logs into a router and does a "show log" to figure out why. In > fact, > one could argue that the vast majority of Google's peers operate this > way, therefore Google could still see significant advantages when > sending messages to other networks, even if they don't when receiving > messages from them. > Plus, this is the kind of thing that could easily be initiated via > snmp > or netconf, and picked up via an snmp trap or other monitoring tool > which already exist. > > * The proposed solution is very difficult deployment wise as both > > peering sides must support the functionality. > I don't see the difficulty. The best case is that the extra level of > communication helps operators run their networks, the worst case is > that > it is unsupported or ignored by the other side because they aren't > expecting it. This is no worse off than we are today. I don't think > anyone is under any delusions that this will ever completely replace > out > of band communications, and certainly not from day 1. > That said, it seems a little odd to argue against standardizing and > implementing a tool which currently doesn't help you because it hasn't > been standardized and implemented. Over time more and more devices > will > be able to support it, as networks upgrade their router code. Until > then, it causes no harm, generates no additional work-load, and the > sending party will know if the other side supports the advisory > capability and is even capable of receiving the message. > > As pointed out yesterday by Keyur Patel or for that matter by Pedro > > Marques when in July 2002 INFORM draft was discussed we are in no > > position to automate all possible actions on the receiver of such > > warning. This is the other side's operator which can in turn make > some > > decisions. (Note that for the reload itself there are other > proposals > > for example one by Bruno - on how to make it graceful). > I was actually afraid that this might be the reaction when I saw the > example use of signaling the approach of a max-prefix limit. Clearly a > structured message such as the INFORM draft is a better way to go > about > signaling something like this, but I think the point being made is > that > an advisory message would at least provide a possible mechanism for > communicating this where today there is none. The ability to send a > free-form message has the advantage of being able to adapt to any > situation that operators might find, instead of requiring the IETF to > think up every possible message type beforehand. > > * To simplify the solution as well as avoid the must for protocol > > changes to make it working. There is one protocol enhancement I will > > propose instead which could be just an optimization ie solution can > work > > without it. > This feature seems to trivial and easy to implement that I have a hard > time thinking of it as a true protocol change. Think of it as an > extremely simple method of interprovider communication which just > happens to piggyback on the existing BGP protocol for no other reason > than that BGP is the only real interprovider protocol to piggyback on. > > * To use automated out of band email based notification directly > > targeting corresponding NOC or admin of the peer, but auto generated > > from the router itself > > > > * To optionally allow for auto-receive of the per SAFI remote peer's > > admin/noc email address where the advisory messages should be send > to > > > > Coming back to our original diagram: > > > > ___________________________________ > > | | > > ^ v > > NOC_A -> ISP_A @ ASBR_A =3D=3D EBGP =3D=3D ASBR_B @ ISP_B -> NOC_B > One significant advantage to in-band signaling over BGP is the built > in > authentication mechanism. By its very nature it is impossible to send > to > or receive from someone who is not a directly connected and configured > BGP peer. The existence of the BGP session itself proves both the > direct > relationship, and simply and securely associates the message with a > specific peer and BGP session. It also serves to get the message > delivered directly to the people who are most interested in seeing it, > the engineering/operations staff on the other side of the connection > who > have access to the router in question. > To implement this via an out-of-band signaling method, you would need > yet another layer 8 signaling to negotiate NOC contact information and > an authentication mechanism, which must then be kept up to date using > more layer 8 signaling. This is essentially the system of > inter-network > communication we use today, it just takes the form of e-mails, > telephone > numbers, and the occasional post to operators mailing lists trying to > negotiate a signaling path to someone clueful. You would also need to > deliver the out of band message via some other mechanism such as the > Internet, which one could consider less secure than delivering it via > the existing direct connection between the two routers in question. > This > might also require a full table, which is intentionally not configured > on many border routers as an anti-traffic injection mechanism. > I believe most large networks with a complex management structure > already have existing (plus working and vetted) mechanisms for > collecting data coming in from distributed routers and feeding it back > to centralized monitoring systems, so this would be a natural > extension > of that functionality. Adding another out of band communications > infrastructure seems significantly more complex, and significantly > less > likely to be implementable in the near future. > As any network operator who lived through the great BGP MD5 scare is > well aware, communication with third party networks is difficult at > best, and painful or impossible at worst. Consider for example the > process that goes on every time a BGP session flaps. NOC_A receives a > monitoring alert/trap about the session, then tries to determine if > this > is an event they were expecting (by checking for layer 8 communication > such as e-mails on the subject), and if they can't find it they then > initiate communication with NOC_B via a mechanism like e-mail or > telephone inquiring about the event. NOC_B then has to determine if > this > is an event they were expecting, by searching their own e-mails or > maintenance calendars, or talking to their engineering/ops group. > Anyone > who has ever done maintenance on an exchange point router with a few > hundred peers is well aware of the dozens of unnecessary e-mails or > calls this will generate, even if a maintenance notification was sent > out. This also does nothing to address the case of an emergency > maintenance, such as an unscheduled but engineering initiated reload. > > In unplanned threshold based events the only difference is that this > is > > not NOC_A's operator but ASBR_A generating the msg itself. > > > > Examples of planned messages/warnings: > > > > # router reload > > # peer hard clear > > > > Examples of unplanned threshold based messages: > > > > # prefix-limit reaching X% > > # dampening applied or about to be applied on prefix Z > > etc... > I agree that structured messages certainly have their place, and I > agree > that prefix-limit reaching/exceeded/etc is certainly best served by > that > type of message, but I don't think this replaces the benefits of a > free-form text message. There are already notification messages for a > peer hard clear, but they aren't capable of telling the other side WHY > the session was cleared. > This issue reaches beyond the world of protocol design, and plants > itself firmly in the realm of the network operator community. > Certainly > every network operator I've talked to has all but jumped for joy at > the > prospect of having this functionality, and I'm certain we can find a > few > of them to state as much on this list. The only thing the IETF needs > to > do is provide the communication mechanism (which is fortunately > extremely simple to do), and then leave the network operators to use > the > tool as they see fit. > -- > Richard A Steenbergen > [1]http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 > 2CBC) > _______________________________________________ > Idr mailing list > Idr@ietf.org > [2]https://www.ietf.org/mailman/listinfo/idr >=20 > References >=20 > 1. http://www.e-gerbil.net/ras > 2. https://www.ietf.org/mailman/listinfo/idr --=20 -m =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Key fingerprint =3D 8E48 6CD0 6D2B 538E 264B D1D0 21E2 E7EE A40F 2A0B gpg --keyserver wwwkeys.pgp.net --recv-keys 0xA40F2A0B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iD8DBQFJyTwwIeLn7qQPKgsRAt0UAJ9q/f54pg+/SeMozyrN0fiHFG/+ZQCfVoAP Asw97om1R/w3FGQUlOxU9OI= =S8Cp -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From robert@raszuk.net Tue Mar 24 13:15:29 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A67A3A68BA for ; Tue, 24 Mar 2009 13:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc0MAtWi3AmU for ; Tue, 24 Mar 2009 13:15:28 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 09F793A67B6 for ; Tue, 24 Mar 2009 13:15:27 -0700 (PDT) Received: (qmail 15287 invoked by uid 399); 24 Mar 2009 20:16:19 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.5.107) by mail37.opentransfer.com with SMTP; 24 Mar 2009 20:16:19 -0000 Message-ID: <49C93F90.5080403@raszuk.net> Date: Tue, 24 Mar 2009 13:16:16 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Richard A Steenbergen References: <49C903E0.4070604@raszuk.net> <20090324185814.GF51443@gerbil.cluepon.net> In-Reply-To: <20090324185814.GF51443@gerbil.cluepon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "SCHOLL, TOM \(ATTLABS\)" , idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:15:29 -0000 Hi Richard & others, > On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote: >> * Parsing is an issue on the receiving side. Imagine the case how >> efficient and doable this solution is considering that your ASBR may be >> peering to 4000 up/down-stream peers as pointed out by Vijay. Each of >> those 4000 peers would first need to be able to support such parsing, >> understand to notify it's own administrator or NOC. > > One thing to keep in mind is that for every Google sized network on the > Internet, there are thousands of smaller sized networks with very > different needs. I'm not arguing that it doesn't make sense for Google > to try and design a system which keeps humans off the routers, but for > the vast majority of the world when something goes down there is a human > who logs into a router and does a "show log" to figure out why. In fact, > one could argue that the vast majority of Google's peers operate this > way, therefore Google could still see significant advantages when > sending messages to other networks, even if they don't when receiving > messages from them. I fully agree with this as well. I know there are thousands of smaller networks. I hope nothing what I said contradicts this. The goal is to find a solution which works for all networks sizes not just for the small ones. And IMHO the solution I proposed does work for both .. large and small networks equally well. > Plus, this is the kind of thing that could easily be initiated via snmp > or netconf, and picked up via an snmp trap or other monitoring tool > which already exist. Agreed too. > That said, it seems a little odd to argue against standardizing and > implementing a tool which currently doesn't help you because it hasn't > been standardized and implemented. Over time more and more devices will > be able to support it, as networks upgrade their router code. Until > then, it causes no harm, generates no additional work-load, and the > sending party will know if the other side supports the advisory > capability and is even capable of receiving the message. I am not arguing against standardizing a tool. If you read my mail right I in fact proposed to standardize and enhancement which will make similar tool, as flexible as the one proposed with more benefits more accurate then what we have today. I just don't see a benefit to use routing protocol (here BGP) to send an SMS to a peering router when we know ahead of time that the router will not do anything with it other then log to a syslog. Email based auto generated messages from one ASBR to end up in many places automatically ... at peer's admin NOC, at pager, at syslog all automated. This is in contrast to grabbing them from syslog and distributing to all of the above interested parties. > I was actually afraid that this might be the reaction when I saw the > example use of signaling the approach of a max-prefix limit. Clearly a > structured message such as the INFORM draft is a better way to go about > signaling something like this, but I think the point being made is that > an advisory message would at least provide a possible mechanism for > communicating this where today there is none. The ability to send a > free-form message has the advantage of being able to adapt to any > situation that operators might find, instead of requiring the IETF to > think up every possible message type beforehand. 100% agreed !!! I am in full favor and support to send auto generated free form messages. All discussion here is just about in what envelope to put such message not if to put it or not. > To implement this via an out-of-band signaling method, you would need > yet another layer 8 signaling to negotiate NOC contact information and > an authentication mechanism, which must then be kept up to date using > more layer 8 signaling. Nope .. as I indicated NOC info can be auto-negotiated inbound. I see no reason why not. That would be just one new BGP capability as opposed to new BGP message which will need to be parsed, which will take room of your ever starving BGP IO input queues, which will keep real routing information behind not too mention bgp keepalives etc ... I have seen so many BGP input queues issues in different BGP implementations that putting free form text even in the new message type into the same queue where is does not really belong seems to me as an unnecessary risk. To summarize I am all for introducing automation and making operators life easier. I was one myself in the past :) My point is that if we make a decision on what envelope to put such free text messages into let's just consider all factors and risks involved in any choice which is made. Cheers, R. PS. I am not arguing that emial is the best out of band vehicle for this either .. it was the simplest I could think about. But I don't think that BGP4 protocol is. Perhaps there will be other suggestions ..... From dmckay@gmail.com Tue Mar 24 13:24:02 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E3528C137 for ; Tue, 24 Mar 2009 13:24:02 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtwPXn+4ZetJ for ; Tue, 24 Mar 2009 13:24:01 -0700 (PDT) Received: from mail-gx0-f208.google.com (mail-gx0-f208.google.com [209.85.217.208]) by core3.amsl.com (Postfix) with ESMTP id E2B8428C131 for ; Tue, 24 Mar 2009 13:23:21 -0700 (PDT) Received: by gxk4 with SMTP id 4so6880322gxk.13 for ; Tue, 24 Mar 2009 13:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fFRB0BwHbmhYhOdbeOsPs2EtZeMuQHnTrKtTUUHuW+g=; b=Q7g2DNgiO6iMHcs6SSAKdcqdjpxFTqqSX6uU+xCPaiWN6762dhMYX58raUXF9u5hfi rOx2QZprIHNJYJV3L7nk6dQL+p4mlpKAF+y3FuyTcaFWpbdQwmVLaNscsOnjx9sehSp3 AMj9lawOyeOUVfC32JEoICX1dCSRk6jgAPmLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JzK0Li59yRKRP/2UC7cbDsKNDRxTXmOH2Xtb9/bM41DJzD2xQEa26+pDd578ICgTm4 N+uXEXltgPXa/lh27I31CdhYk1nGqEoB7+viLXXUHQGaRkcKVD33C/FyMGicVii/2Gvq 45J9k8CrscdJbSeG0OAXTYMTgO2lqfeTjdSmY= MIME-Version: 1.0 Received: by 10.151.158.9 with SMTP id k9mr3702831ybo.207.1237926252806; Tue, 24 Mar 2009 13:24:12 -0700 (PDT) In-Reply-To: <20090324200152.GA18430@equinix.com> References: <49C903E0.4070604@raszuk.net> <20090324185814.GF51443@gerbil.cluepon.net> <20090324200152.GA18430@equinix.com> Date: Tue, 24 Mar 2009 13:24:12 -0700 Message-ID: <6c8e6d5a0903241324q4d0ec0b5q4f141170c569e6b8@mail.gmail.com> From: David McKay To: Marcelo Schmidt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "SCHOLL, TOM \(ATTLABS\)" , idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:24:02 -0000 Again, +1. 2009/3/24 Marcelo Schmidt : > +1 > > On Tue, Mar 24, 2009 at 11:58:14AM -0700, Richard A Steenbergen wrote: >> >> =A0 =A0On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote: >> =A0 =A0> >> =A0 =A0> * Parsing is an issue on the receiving side. Imagine the case h= ow >> =A0 =A0> efficient and doable this solution is considering that your ASB= R may >> =A0 =A0be >> =A0 =A0> =A0peering =A0to 4000 up/down-stream peers as pointed out by Vi= jay. Each >> =A0 =A0of >> =A0 =A0> =A0those =A04000 =A0peers =A0would =A0first =A0need =A0to =A0be= able to support such >> =A0 =A0parsing, >> =A0 =A0> understand to notify it's own administrator or NOC. >> =A0 =A0One =A0thing =A0to =A0keep in mind is that for every Google sized= network on >> =A0 =A0the >> =A0 =A0Internet, there are thousands of smaller sized networks with very >> =A0 =A0different needs. I'm not arguing that it doesn't make sense for G= oogle >> =A0 =A0to try and design a system which keeps humans off the routers, bu= t for >> =A0 =A0the =A0vast =A0majority =A0of =A0the world when something goes do= wn there is a >> =A0 =A0human >> =A0 =A0who =A0logs =A0into =A0a =A0router and does a "show log" to figur= e out why. In >> =A0 =A0fact, >> =A0 =A0one could argue that the vast majority of Google's peers operate = this >> =A0 =A0way, therefore Google could still see significant advantages when >> =A0 =A0sending messages to other networks, even if they don't when recei= ving >> =A0 =A0messages from them. >> =A0 =A0Plus, =A0this =A0is =A0the =A0kind of thing that could easily be = initiated via >> =A0 =A0snmp >> =A0 =A0or netconf, and picked up via an snmp trap or other monitoring to= ol >> =A0 =A0which already exist. >> =A0 =A0> * The proposed solution is very difficult deployment wise as bo= th >> =A0 =A0> peering sides must support the functionality. >> =A0 =A0I don't see the difficulty. The best case is that the extra level= of >> =A0 =A0communication =A0helps =A0operators =A0run their networks, the wo= rst case is >> =A0 =A0that >> =A0 =A0it is unsupported or ignored by the other side because they aren'= t >> =A0 =A0expecting it. This is no worse off than we are today. I don't thi= nk >> =A0 =A0anyone =A0is =A0under any delusions that this will ever completel= y replace >> =A0 =A0out >> =A0 =A0of band communications, and certainly not from day 1. >> =A0 =A0That said, it seems a little odd to argue against standardizing a= nd >> =A0 =A0implementing a tool which currently doesn't help you because it h= asn't >> =A0 =A0been =A0standardized =A0and =A0implemented. =A0Over time more and= more devices >> =A0 =A0will >> =A0 =A0be able to support it, as networks upgrade their router code. Unt= il >> =A0 =A0then, it causes no harm, generates no additional work-load, and t= he >> =A0 =A0sending party will know if the other side supports the advisory >> =A0 =A0capability and is even capable of receiving the message. >> =A0 =A0> As pointed out yesterday by Keyur Patel or for that matter by P= edro >> =A0 =A0> Marques when in July 2002 INFORM draft was discussed we are in = no >> =A0 =A0> position to automate all possible actions on the receiver of su= ch >> =A0 =A0> =A0warning. =A0This =A0is the other side's operator which can i= n turn make >> =A0 =A0some >> =A0 =A0> =A0decisions. =A0(Note =A0that =A0for =A0the =A0reload =A0itsel= f =A0there =A0are other >> =A0 =A0proposals >> =A0 =A0> for example one by Bruno - on how to make it graceful). >> =A0 =A0I was actually afraid that this might be the reaction when I saw = the >> =A0 =A0example use of signaling the approach of a max-prefix limit. Clea= rly a >> =A0 =A0structured =A0message =A0such =A0as =A0the =A0INFORM draft is a b= etter way to go >> =A0 =A0about >> =A0 =A0signaling =A0something =A0like =A0this, =A0but I think the point = being made is >> =A0 =A0that >> =A0 =A0an advisory message would at least provide a possible mechanism f= or >> =A0 =A0communicating this where today there is none. The ability to send= a >> =A0 =A0free-form message has the advantage of being able to adapt to any >> =A0 =A0situation that operators might find, instead of requiring the IET= F to >> =A0 =A0think up every possible message type beforehand. >> =A0 =A0> * To simplify the solution as well as avoid the must for protoc= ol >> =A0 =A0> changes to make it working. There is one protocol enhancement I= will >> =A0 =A0> =A0propose instead which could be just an optimization ie solut= ion can >> =A0 =A0work >> =A0 =A0> without it. >> =A0 =A0This feature seems to trivial and easy to implement that I have a= hard >> =A0 =A0time thinking of it as a true protocol change. Think of it as an >> =A0 =A0extremely simple method of interprovider communication which just >> =A0 =A0happens to piggyback on the existing BGP protocol for no other re= ason >> =A0 =A0than that BGP is the only real interprovider protocol to piggybac= k on. >> =A0 =A0> * To use automated out of band email based notification directl= y >> =A0 =A0> targeting corresponding NOC or admin of the peer, but auto gene= rated >> =A0 =A0> from the router itself >> =A0 =A0> >> =A0 =A0> * To optionally allow for auto-receive of the per SAFI remote p= eer's >> =A0 =A0> =A0admin/noc =A0email address where the advisory messages shoul= d be send >> =A0 =A0to >> =A0 =A0> >> =A0 =A0> Coming back to our original diagram: >> =A0 =A0> >> =A0 =A0> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0________________________= ___________ >> =A0 =A0> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 =A0> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 v >> =A0 =A0> NOC_A -> ISP_A @ ASBR_A =3D=3D EBGP =3D=3D ASBR_B @ ISP_B -> NO= C_B >> =A0 =A0One =A0significant =A0advantage to in-band signaling over BGP is = the built >> =A0 =A0in >> =A0 =A0authentication =A0mechanism. By its very nature it is impossible = to send >> =A0 =A0to >> =A0 =A0or receive from someone who is not a directly connected and confi= gured >> =A0 =A0BGP =A0peer. =A0The =A0existence =A0of =A0the BGP session itself = proves both the >> =A0 =A0direct >> =A0 =A0relationship, and simply and securely associates the message with= a >> =A0 =A0specific peer and BGP session. It also serves to get the message >> =A0 =A0delivered directly to the people who are most interested in seein= g it, >> =A0 =A0the =A0engineering/operations =A0staff on the other side of the c= onnection >> =A0 =A0who >> =A0 =A0have access to the router in question. >> =A0 =A0To implement this via an out-of-band signaling method, you would = need >> =A0 =A0yet another layer 8 signaling to negotiate NOC contact informatio= n and >> =A0 =A0an authentication mechanism, which must then be kept up to date u= sing >> =A0 =A0more =A0 layer =A0 8 =A0 signaling. =A0 This =A0is =A0essentially= =A0the =A0system =A0of >> =A0 =A0inter-network >> =A0 =A0communication =A0we =A0use =A0today, =A0it =A0just =A0takes =A0th= e =A0form of e-mails, >> =A0 =A0telephone >> =A0 =A0numbers, and the occasional post to operators mailing lists tryin= g to >> =A0 =A0negotiate a signaling path to someone clueful. You would also nee= d to >> =A0 =A0deliver the out of band message via some other mechanism such as = the >> =A0 =A0Internet, which one could consider less secure than delivering it= via >> =A0 =A0the =A0existing =A0direct =A0connection between the two routers i= n question. >> =A0 =A0This >> =A0 =A0might also require a full table, which is intentionally not confi= gured >> =A0 =A0on many border routers as an anti-traffic injection mechanism. >> =A0 =A0I believe most large networks with a complex management structure >> =A0 =A0already have existing (plus working and vetted) mechanisms for >> =A0 =A0collecting data coming in from distributed routers and feeding it= back >> =A0 =A0to =A0centralized =A0monitoring =A0systems, =A0so =A0this =A0woul= d =A0be =A0a =A0natural >> =A0 =A0extension >> =A0 =A0of that functionality. Adding another out of band communications >> =A0 =A0infrastructure =A0seems =A0significantly =A0more =A0complex, and = significantly >> =A0 =A0less >> =A0 =A0likely to be implementable in the near future. >> =A0 =A0As any network operator who lived through the great BGP MD5 scare= is >> =A0 =A0well aware, communication with third party networks is difficult = at >> =A0 =A0best, and painful or impossible at worst. Consider for example th= e >> =A0 =A0process that goes on every time a BGP session flaps. NOC_A receiv= es a >> =A0 =A0monitoring =A0alert/trap =A0about =A0the session, then tries to d= etermine if >> =A0 =A0this >> =A0 =A0is an event they were expecting (by checking for layer 8 communic= ation >> =A0 =A0such as e-mails on the subject), and if they can't find it they t= hen >> =A0 =A0initiate communication with NOC_B via a mechanism like e-mail or >> =A0 =A0telephone =A0inquiring =A0about =A0the event. NOC_B then has to d= etermine if >> =A0 =A0this >> =A0 =A0is an event they were expecting, by searching their own e-mails o= r >> =A0 =A0maintenance =A0calendars, =A0or =A0talking =A0to =A0their enginee= ring/ops group. >> =A0 =A0Anyone >> =A0 =A0who has ever done maintenance on an exchange point router with a = few >> =A0 =A0hundred peers is well aware of the dozens of unnecessary e-mails = or >> =A0 =A0calls this will generate, even if a maintenance notification was = sent >> =A0 =A0out. This also does nothing to address the case of an emergency >> =A0 =A0maintenance, such as an unscheduled but engineering initiated rel= oad. >> =A0 =A0> In unplanned threshold based events the only difference is that= this >> =A0 =A0is >> =A0 =A0> not NOC_A's operator but ASBR_A generating the msg itself. >> =A0 =A0> >> =A0 =A0> Examples of planned messages/warnings: >> =A0 =A0> >> =A0 =A0> # router reload >> =A0 =A0> # peer hard clear >> =A0 =A0> >> =A0 =A0> Examples of unplanned threshold based messages: >> =A0 =A0> >> =A0 =A0> # prefix-limit reaching X% >> =A0 =A0> # dampening applied or about to be applied on prefix Z >> =A0 =A0> etc... >> =A0 =A0I =A0agree =A0that =A0structured =A0messages certainly have their= place, and I >> =A0 =A0agree >> =A0 =A0that =A0prefix-limit =A0reaching/exceeded/etc =A0is certainly bes= t served by >> =A0 =A0that >> =A0 =A0type of message, but I don't think this replaces the benefits of = a >> =A0 =A0free-form text message. There are already notification messages f= or a >> =A0 =A0peer hard clear, but they aren't capable of telling the other sid= e WHY >> =A0 =A0the session was cleared. >> =A0 =A0This issue reaches beyond the world of protocol design, and plant= s >> =A0 =A0itself =A0firmly =A0in =A0the =A0realm =A0of =A0the =A0network = =A0operator =A0community. >> =A0 =A0Certainly >> =A0 =A0every =A0network =A0operator =A0I've talked to has all but jumped= for joy at >> =A0 =A0the >> =A0 =A0prospect =A0of =A0having this functionality, and I'm certain we c= an find a >> =A0 =A0few >> =A0 =A0of =A0them =A0to state as much on this list. The only thing the I= ETF needs >> =A0 =A0to >> =A0 =A0do is provide the communication mechanism (which is fortunately >> =A0 =A0extremely =A0simple =A0to do), and then leave the network operato= rs to use >> =A0 =A0the >> =A0 =A0tool as they see fit. >> =A0 =A0-- >> =A0 =A0Richard A Steenbergen >> =A0 =A0[1]http://www.e-gerbil.net/ras >> =A0 =A0GPG =A0Key =A0ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 = 5ECA F8B1 >> =A0 =A02CBC) >> =A0 =A0_______________________________________________ >> =A0 =A0Idr mailing list >> =A0 =A0Idr@ietf.org >> =A0 =A0[2]https://www.ietf.org/mailman/listinfo/idr >> >> References >> >> =A0 =A01. http://www.e-gerbil.net/ras >> =A0 =A02. https://www.ietf.org/mailman/listinfo/idr > > -- > -m > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Key fingerprint =3D 8E48 6CD0 6D2B 538E 264B =A0D1D0 21E2 E7EE A40F 2A0B > gpg --keyserver wwwkeys.pgp.net --recv-keys 0xA40F2A0B > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --=20 Dave McKay dmckay@gmail.com From kris.foster@gmail.com Tue Mar 24 13:33:31 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC29428C164 for ; Tue, 24 Mar 2009 13:33:31 -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=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIbeh1YHyiD9 for ; Tue, 24 Mar 2009 13:33:30 -0700 (PDT) Received: from mail1.sjc1.bitgravity.com (mail1.sjc1.bitgravity.com [209.131.97.19]) by core3.amsl.com (Postfix) with ESMTP id 4B78228C2F7 for ; Tue, 24 Mar 2009 13:33:30 -0700 (PDT) Received: from [209.131.110.178] (helo=netops-178.sfo1.bitgravity.com) by mail1.sjc1.bitgravity.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LmDKF-000EhN-Mh; Tue, 24 Mar 2009 13:34:19 -0700 Message-Id: <0E7E1C0E-C585-4B5B-AB33-981651764CFE@gmail.com> From: kris foster To: Richard A Steenbergen In-Reply-To: <20090324185814.GF51443@gerbil.cluepon.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 13:34:18 -0700 References: <49C903E0.4070604@raszuk.net> <20090324185814.GF51443@gerbil.cluepon.net> X-Mailer: Apple Mail (2.930.3) Cc: "SCHOLL, TOM \(ATTLABS\)" , idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:33:31 -0000 I support Richard's comments On Mar 24, 2009, at 11:58 AM, Richard A Steenbergen wrote: > On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote: >> >> * Parsing is an issue on the receiving side. Imagine the case how >> efficient and doable this solution is considering that your ASBR >> may be >> peering to 4000 up/down-stream peers as pointed out by Vijay. Each of >> those 4000 peers would first need to be able to support such parsing, >> understand to notify it's own administrator or NOC. > > One thing to keep in mind is that for every Google sized network on > the > Internet, there are thousands of smaller sized networks with very > different needs. I'm not arguing that it doesn't make sense for Google > to try and design a system which keeps humans off the routers, but for > the vast majority of the world when something goes down there is a > human > who logs into a router and does a "show log" to figure out why. In > fact, > one could argue that the vast majority of Google's peers operate this > way, therefore Google could still see significant advantages when > sending messages to other networks, even if they don't when receiving > messages from them. > > Plus, this is the kind of thing that could easily be initiated via > snmp > or netconf, and picked up via an snmp trap or other monitoring tool > which already exist. > >> * The proposed solution is very difficult deployment wise as both >> peering sides must support the functionality. > > I don't see the difficulty. The best case is that the extra level of > communication helps operators run their networks, the worst case is > that > it is unsupported or ignored by the other side because they aren't > expecting it. This is no worse off than we are today. I don't think > anyone is under any delusions that this will ever completely replace > out > of band communications, and certainly not from day 1. > > That said, it seems a little odd to argue against standardizing and > implementing a tool which currently doesn't help you because it hasn't > been standardized and implemented. Over time more and more devices > will > be able to support it, as networks upgrade their router code. Until > then, it causes no harm, generates no additional work-load, and the > sending party will know if the other side supports the advisory > capability and is even capable of receiving the message. > >> As pointed out yesterday by Keyur Patel or for that matter by Pedro >> Marques when in July 2002 INFORM draft was discussed we are in no >> position to automate all possible actions on the receiver of such >> warning. This is the other side's operator which can in turn make >> some >> decisions. (Note that for the reload itself there are other proposals >> for example one by Bruno - on how to make it graceful). > > I was actually afraid that this might be the reaction when I saw the > example use of signaling the approach of a max-prefix limit. Clearly a > structured message such as the INFORM draft is a better way to go > about > signaling something like this, but I think the point being made is > that > an advisory message would at least provide a possible mechanism for > communicating this where today there is none. The ability to send a > free-form message has the advantage of being able to adapt to any > situation that operators might find, instead of requiring the IETF to > think up every possible message type beforehand. > >> * To simplify the solution as well as avoid the must for protocol >> changes to make it working. There is one protocol enhancement I will >> propose instead which could be just an optimization ie solution can >> work >> without it. > > This feature seems to trivial and easy to implement that I have a hard > time thinking of it as a true protocol change. Think of it as an > extremely simple method of interprovider communication which just > happens to piggyback on the existing BGP protocol for no other reason > than that BGP is the only real interprovider protocol to piggyback on. > >> * To use automated out of band email based notification directly >> targeting corresponding NOC or admin of the peer, but auto generated >> from the router itself >> >> * To optionally allow for auto-receive of the per SAFI remote peer's >> admin/noc email address where the advisory messages should be send to >> >> Coming back to our original diagram: >> >> ___________________________________ >> | | >> ^ v >> NOC_A -> ISP_A @ ASBR_A == EBGP == ASBR_B @ ISP_B -> NOC_B > > One significant advantage to in-band signaling over BGP is the built > in > authentication mechanism. By its very nature it is impossible to > send to > or receive from someone who is not a directly connected and configured > BGP peer. The existence of the BGP session itself proves both the > direct > relationship, and simply and securely associates the message with a > specific peer and BGP session. It also serves to get the message > delivered directly to the people who are most interested in seeing it, > the engineering/operations staff on the other side of the connection > who > have access to the router in question. > > To implement this via an out-of-band signaling method, you would need > yet another layer 8 signaling to negotiate NOC contact information and > an authentication mechanism, which must then be kept up to date using > more layer 8 signaling. This is essentially the system of inter- > network > communication we use today, it just takes the form of e-mails, > telephone > numbers, and the occasional post to operators mailing lists trying to > negotiate a signaling path to someone clueful. You would also need to > deliver the out of band message via some other mechanism such as the > Internet, which one could consider less secure than delivering it via > the existing direct connection between the two routers in question. > This > might also require a full table, which is intentionally not configured > on many border routers as an anti-traffic injection mechanism. > > I believe most large networks with a complex management structure > already have existing (plus working and vetted) mechanisms for > collecting data coming in from distributed routers and feeding it back > to centralized monitoring systems, so this would be a natural > extension > of that functionality. Adding another out of band communications > infrastructure seems significantly more complex, and significantly > less > likely to be implementable in the near future. > > As any network operator who lived through the great BGP MD5 scare is > well aware, communication with third party networks is difficult at > best, and painful or impossible at worst. Consider for example the > process that goes on every time a BGP session flaps. NOC_A receives a > monitoring alert/trap about the session, then tries to determine if > this > is an event they were expecting (by checking for layer 8 communication > such as e-mails on the subject), and if they can't find it they then > initiate communication with NOC_B via a mechanism like e-mail or > telephone inquiring about the event. NOC_B then has to determine if > this > is an event they were expecting, by searching their own e-mails or > maintenance calendars, or talking to their engineering/ops group. > Anyone > who has ever done maintenance on an exchange point router with a few > hundred peers is well aware of the dozens of unnecessary e-mails or > calls this will generate, even if a maintenance notification was sent > out. This also does nothing to address the case of an emergency > maintenance, such as an unscheduled but engineering initiated reload. > >> In unplanned threshold based events the only difference is that >> this is >> not NOC_A's operator but ASBR_A generating the msg itself. >> >> Examples of planned messages/warnings: >> >> # router reload >> # peer hard clear >> >> Examples of unplanned threshold based messages: >> >> # prefix-limit reaching X% >> # dampening applied or about to be applied on prefix Z >> etc... > > I agree that structured messages certainly have their place, and I > agree > that prefix-limit reaching/exceeded/etc is certainly best served by > that > type of message, but I don't think this replaces the benefits of a > free-form text message. There are already notification messages for a > peer hard clear, but they aren't capable of telling the other side WHY > the session was cleared. > > This issue reaches beyond the world of protocol design, and plants > itself firmly in the realm of the network operator community. > Certainly > every network operator I've talked to has all but jumped for joy at > the > prospect of having this functionality, and I'm certain we can find a > few > of them to state as much on this list. The only thing the IETF needs > to > do is provide the communication mechanism (which is fortunately > extremely simple to do), and then leave the network operators to use > the > tool as they see fit. > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 > 2CBC) > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ts3127@att.com Tue Mar 24 14:07:36 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900E63A6B45 for ; Tue, 24 Mar 2009 14:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.118 X-Spam-Level: X-Spam-Status: No, score=-106.118 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZpuGPhe+H6I for ; Tue, 24 Mar 2009 14:07:35 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id F0BAF3A6989 for ; Tue, 24 Mar 2009 14:07:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ts3127@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1237928829!40929275!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 17623 invoked from network); 24 Mar 2009 21:07:09 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-3.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 24 Mar 2009 21:07:09 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n2OL6k23030050; Tue, 24 Mar 2009 16:06:46 -0500 Received: from gaalpa1msghub80.ITServices.sbc.com (gaalpa1msghub80.itservices.sbc.com [135.53.26.20]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n2OL6iPv030019; Tue, 24 Mar 2009 16:06:44 -0500 Received: from gaalpa1msgusr73.ITServices.sbc.com ([135.53.8.26]) by gaalpa1msghub80.ITServices.sbc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 17:06:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 17:08:20 -0400 Message-ID: <22087C66F061B24EA008D146B7E9164304213778@gaalpa1msgusr73.ITServices.sbc.com> In-Reply-To: <49C93F90.5080403@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-scholl-idr-advisory-00 Thread-Index: AcmsvWkxPFVl6Cu/Q/+8LCtX0TvGdQABjjCw From: "SCHOLL, TOM (ATTLABS)" To: , "Richard A Steenbergen" X-OriginalArrivalTime: 24 Mar 2009 21:06:43.0793 (UTC) FILETIME=[6F513410:01C9ACC4] X-TM-AS-Product-Ver: SMEX-7.0.0.1607-5.6.1016-16540.002 X-TM-AS-Result: No-0.662700-0.000000-31 Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:07:36 -0000 > PS. I am not arguing that emial is the best out of band=20 > vehicle for this=20 > either .. it was the simplest I could think about. But I=20 > don't think=20 > that BGP4 protocol is. Perhaps there will be other suggestions ..... During the session yesterday, Dave Ward brought up that syslog was a potentially viable option. However, I disagree that opening up UDP/514 to BGP neighbors is the right thing to do. The problem with this is how do you know the datagrams you are receiving are from the BGP neighbor and are not spoofed? Sure, one could say that with TTL-security, you could only accept datagrams with TTL=3D255. But a large amount of peering is done on broadcast LANs where everyone is directly connected to each other (and would appear to be 1-hop away). This is the common configuration at popular Internet exchange locations (AMSIX, LINX, Equinix, Switch & Data aka PAIX). There's no way to guarantee that datagram didn't come from someone else.=20 Also, eBGP-multihop is used at times to peer with devices more than one hop away in settlement-free environments. TTL security would not be useful in this example as the TTL would come in < 255 from the legitimate neighbor. From robert@raszuk.net Tue Mar 24 14:16:17 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D46D3A6BC9 for ; Tue, 24 Mar 2009 14:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vEwvI1NGMN2 for ; Tue, 24 Mar 2009 14:16:16 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 29EE73A6BFF for ; Tue, 24 Mar 2009 14:16:16 -0700 (PDT) Received: (qmail 1863 invoked by uid 399); 24 Mar 2009 21:17:07 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.5.107) by mail37.opentransfer.com with SMTP; 24 Mar 2009 21:17:07 -0000 Message-ID: <49C94DCF.9080300@raszuk.net> Date: Tue, 24 Mar 2009 14:17:03 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "SCHOLL, TOM (ATTLABS)" References: <22087C66F061B24EA008D146B7E9164304213778@gaalpa1msgusr73.ITServices.sbc.com> In-Reply-To: <22087C66F061B24EA008D146B7E9164304213778@gaalpa1msgusr73.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:16:17 -0000 Hi Tom, >> PS. I am not arguing that emial is the best out of band >> vehicle for this >> either .. it was the simplest I could think about. But I >> don't think >> that BGP4 protocol is. Perhaps there will be other suggestions ..... > > During the session yesterday, Dave Ward brought up that syslog was a > potentially viable option. However, I disagree that opening up UDP/514 > to BGP neighbors is the right thing to do. > > The problem with this is how do you know the datagrams you are receiving > are from the BGP neighbor and are not spoofed? Sure, one could say that > with TTL-security, you could only accept datagrams with TTL=255. But a > large amount of peering is done on broadcast LANs where everyone is > directly connected to each other (and would appear to be 1-hop away). > This is the common configuration at popular Internet exchange locations > (AMSIX, LINX, Equinix, Switch & Data aka PAIX). There's no way to > guarantee that datagram didn't come from someone else. Actually why not ? If we make it MD5 or IPSec secured ? > Also, eBGP-multihop is used at times to peer with devices more than one > hop away in settlement-free environments. TTL security would not be > useful in this example as the TTL would come in < 255 from the > legitimate neighbor. Again MD5 or IPSec syslog protocol would be just fine for those as well. Thinking about good comments from Richard on the security aspect of using email as the envelope I have two comments ... * I did not say that this communication should be done in open full of spam internet email system. One can over couple of hours build a private set of smtp hosts fully isolated from reception of the external spam :) * Even if this WG insists on using BGP .. just because it is there already .. I would strongly suggest not to mix is with routing information over the same session. Cheers, R. From jsw@inconcepts.biz Tue Mar 24 17:08:25 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEC03A682B for ; Tue, 24 Mar 2009 17:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.147 X-Spam-Level: * X-Spam-Status: No, score=1.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVVfNrttyXxk for ; Tue, 24 Mar 2009 17:08:24 -0700 (PDT) Received: from odyssey.inconcepts.biz (unknown [69.31.82.162]) by core3.amsl.com (Postfix) with SMTP id B04B83A63CB for ; Tue, 24 Mar 2009 17:08:24 -0700 (PDT) Received: (qmail 12447 invoked from network); 25 Mar 2009 00:09:15 -0000 Received: from 96-28-163-106.dhcp.insightbb.com (HELO ?96.28.163.106?) (96.28.163.106) by colo-69-31-82-163.pilosoft.com with SMTP; 25 Mar 2009 00:09:15 -0000 From: Jeff S Wheeler To: idr@ietf.org Content-Type: text/plain Organization: Innovative Network Concepts LLC Date: Tue, 24 Mar 2009 20:11:19 -0400 Message-Id: <1237939879.16338.199.camel@guardian.inconcepts.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:09:09 -0000 On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote: > * To use automated out of band email based notification directly > targeting corresponding NOC or admin of the peer, but auto generated > from the router itself You want the router to write email to "4000" NOCs informing them of pending maintenance? I'm pretty sure there are better tools available for that. I like the idea that the same person who logs onto the router to find out why a neighbor is down will have information about that maintenance available in their log or `show bgp neighbor` output. Then they won't generate a useless email to your NOC asking why the session to you is down, only to receive an "read the maintenance notice" reply. > * To optionally allow for auto-receive of the per SAFI remote peer's > admin/noc email address where the advisory messages should be send to Why are we adding all this complexity to get information into an email when it can be on the router? While you're at it, let's process BGP NLRI off-line because making something more convenient and accessible is obviously against the nature of computing systems. > * No need to modify BGP protocol (only if at all as an option we Unless you want those email addresses to be learnt from the BGP neighbor as you suggest. > * Deployable today via already existing operating systems Really? I didn't know IOS knew how to write and send email. > * Follows other standard industry practices where for example unix > hosts or good firewalls have such admin email configurable already ... > why router's don't ? I didn't know there were firewalls that send email to third-parties, but it wouldn't surprise me if someone developed a product this stupid. What surprises me is that a network operator would think this is a good idea. Your email notion is not as crazy as a Sonicwall that looks up abuse addresses in the RIR whois and sends a nasty-gram every time it detects a port scan, but I don't think firewalls that know how to send email are necessarily an example of good behavior. > * No need to modify and parse anything at the potential 1000s of peers. Your email-based solution has an advantage over BGP advisory because of message parsing? Wait, are we going to parse those NOC emails and do something useful with them? If so, we better write a tool for that, just like we would need one to parse information from the router syslog messages or `show bgp neighbor`. If not, a human is going to have to read those messages. How does your proposal have an advantage in either parsing work or savings in man-hours vs the Scholl plan? -- Jeff S Wheeler +1-212-981-0607 Sr Network Operator / Innovative Network Concepts From knoll@etit.tu-chemnitz.de Tue Mar 24 17:15:35 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205E93A697C for ; Tue, 24 Mar 2009 17:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esPpMjscdnTo for ; Tue, 24 Mar 2009 17:15:34 -0700 (PDT) Received: from lana.hrz.tu-chemnitz.de (lana.hrz.tu-chemnitz.de [134.109.132.3]) by core3.amsl.com (Postfix) with ESMTP id 2F05D3A6953 for ; Tue, 24 Mar 2009 17:15:34 -0700 (PDT) Received: from galba.hrz.tu-chemnitz.de ([134.109.133.156] helo=mailbox.hrz.tu-chemnitz.de) by lana.hrz.tu-chemnitz.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LmGnA-0007Ka-AT for idr@ietf.org; Wed, 25 Mar 2009 01:16:24 +0100 Received: from tor.hrz.tu-chemnitz.de ([134.109.133.13]) by mailbox.hrz.tu-chemnitz.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LmGnA-0007Dx-7o for idr@ietf.org; Wed, 25 Mar 2009 01:16:24 +0100 Received: from tor.hrz.tu-chemnitz.de (localhost.localdomain [127.0.0.1]) by tor.hrz.tu-chemnitz.de (8.13.8/8.12.10) with ESMTP id n2P0GOvN010615 for ; Wed, 25 Mar 2009 01:16:24 +0100 Received: from localhost (tkn@localhost) by tor.hrz.tu-chemnitz.de (8.13.8/8.12.10/Submit) with ESMTP id n2P0GNXC010611 for ; Wed, 25 Mar 2009 01:16:23 +0100 X-Authentication-Warning: tor.hrz.tu-chemnitz.de: tkn owned process doing -bs Date: Wed, 25 Mar 2009 01:16:22 +0100 (MET) From: "Thomas M. Knoll" X-X-Sender: tkn@tor.hrz.tu-chemnitz.de To: idr@ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Scan-Signature: 06280db8b748e42b2cf8978feac4b446 Subject: [Idr] partial bit for ext. communities? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:15:35 -0000 Folks, within my presentation yesterday, I mentioned my observation about "unknown" extended communities, which are relayed in BGP nodes without being marked as partially processed. see slide 13 in http://www3.ietf.org/proceedings/09mar/slides/idr-5.pdf I was sending 4 of my new ext. communities (of regular type), which got bundled into an extended community attribute and transferred to an commercial router. This in turn relayed the attribute with the partial bit being cleared. This router behaviour is arguably OK, since it did understand the extended community attribute of type 16 and obviously did not care about the contained bunch of not yet known ext. communities (of regular type 0x04). By means of this email, I would like to hear your opinion, whether you are contended with such behaviour OR whether a partial bit in each extended community would make the processing status of individual ext. communities clearer. As far as I am aware of, there are no other extended communities of regular type around (besides my own ones - 0x04, 0x44, 0x40), which would give the chance to have a flags field next to the ext. community type, which could host the proposed ext. community specific partial bit. Thomas. From yakov@juniper.net Tue Mar 24 17:23:16 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23BA3A682B for ; Tue, 24 Mar 2009 17:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1spYFXE-8gu7 for ; Tue, 24 Mar 2009 17:23:16 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id EB7013A63CB for ; Tue, 24 Mar 2009 17:23:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKScl5acRYFqKP6NOu5n1Cz9Yw05O9N4T8@postini.com; Tue, 24 Mar 2009 17:24:08 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 24 Mar 2009 17:20:37 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 17:20:37 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 17:20:36 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 17:20:35 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2P0KZM68604; Tue, 24 Mar 2009 17:20:35 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903250020.n2P0KZM68604@magenta.juniper.net> To: David Ward MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59228.1237940435.1@juniper.net> Date: Tue, 24 Mar 2009 17:20:35 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 25 Mar 2009 00:20:35.0924 (UTC) FILETIME=[849B8940:01C9ACDF] Cc: Yakov Rekhter , Sue Hares , idr@ietf.org Subject: [Idr] draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:23:16 -0000 Dave, Combination of comments received on the mailing list, and poll at the IDR WG meeting indicates IDR WG consensus to ask IESG to advance draft-ietf-idr-flow-spec to Proposed Standard. Yakov. From will@harg.net Tue Mar 24 17:33:52 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51E03A68A4 for ; Tue, 24 Mar 2009 17:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL2b00ekPAde for ; Tue, 24 Mar 2009 17:33:52 -0700 (PDT) Received: from microserf.flarg.net (microserf.flarg.net [195.177.252.111]) by core3.amsl.com (Postfix) with ESMTP id 0066A3A6880 for ; Tue, 24 Mar 2009 17:33:51 -0700 (PDT) Received: from 193-47-147-52.11.uknof.org.uk ([193.47.147.52]) by microserf.flarg.net with asmtp (Exim 3.35 #1 (Debian)) id 1LmH4g-0002fz-00; Wed, 25 Mar 2009 00:34:30 +0000 Message-ID: <49C97C14.4080705@harg.net> Date: Wed, 25 Mar 2009 00:34:28 +0000 From: Will Hargrave User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Richard A Steenbergen References: <49C903E0.4070604@raszuk.net> <20090324185814.GF51443@gerbil.cluepon.net> In-Reply-To: <20090324185814.GF51443@gerbil.cluepon.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:33:52 -0000 Richard A Steenbergen wrote: > This issue reaches beyond the world of protocol design, and plants > itself firmly in the realm of the network operator community. > Certainly every network operator I've talked to has all but jumped > for joy at the prospect of having this functionality, and I'm certain > we can find a few of them to state as much on this list. The only > thing the IETF needs to do is provide the communication mechanism > (which is fortunately extremely simple to do), and then leave the > network operators to use the tool as they see fit. +1 from here. A good comparison which could be drawn here is the 'interface description' sub-TLV in pseudowire signalling [1]. Absolutely no use to routers, but is an optional human-readable string provided solely for the benefit of the humans attached to the router. It is carried alongside existing NLRI using a routing protocol - in this case LDP - as an extension for the operator's convenience. IMO syslog, email, md5, ipsec, are unnecessary complexities in this case - as proposed this solution would be immediately useful with no further complex infrastructure deployment necessary. It might even build real demand for more advanced features in this area in future. [1] for example, see RFC4447 section 5.5 From robert@raszuk.net Tue Mar 24 17:59:34 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6AB3A6B27 for ; Tue, 24 Mar 2009 17:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8Ov8t+QHV0U for ; Tue, 24 Mar 2009 17:59:33 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 2F6443A6B1B for ; Tue, 24 Mar 2009 17:59:33 -0700 (PDT) Received: (qmail 5384 invoked by uid 399); 25 Mar 2009 01:00:24 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.50.47) by mail37.opentransfer.com with SMTP; 25 Mar 2009 01:00:24 -0000 Message-ID: <49C98226.7050901@raszuk.net> Date: Tue, 24 Mar 2009 18:00:22 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jeff S Wheeler References: <1237939879.16338.199.camel@guardian.inconcepts.net> In-Reply-To: <1237939879.16338.199.camel@guardian.inconcepts.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:59:34 -0000 Hi Jeff, > I like the idea that the same person who logs onto the router > to find out why a neighbor is down will have information about that > maintenance available in their log or `show bgp neighbor` output. Then > they won't generate a useless email to your NOC asking why the session > to you is down, only to receive an "read the maintenance notice" reply. > > Why are we adding all this complexity to get information into an email > when it can be on the router? Do you keep your syslog on the router ? I know operators who expressed interest in having a sort of BGP history database as their customers can month later come and ask why my sessions were down, why I was not able to reach ABC via your AS 4 weeks back between Mon 4:30-5:30 AM etc ... I don't know why in particular session down/reset is the only BGP event that should be logged in no matter what mechanism is chosen to be used. Wouldn't you like to know who is behind at any given moment some prefix flapping ? Wouldn't you be curios why your ASBR is being bombarded by stream of bgp route refresh messages, why some peers are are falling from your peer group as too slow ? On the other hand the model you suggest to receive a message, keep it "on the router" and only when logged in have it handy there for troubleshooting seems not in the spirit of passing warning like notifications for example prefix-limit reaching threshold. As I know that many operators are very creative I am sure the list of such text events to pass between peers will just grow. The solution should be robust to accommodate it. >> * No need to modify BGP protocol (only if at all as an option we > > Unless you want those email addresses to be learnt from the BGP neighbor > as you suggest. But the slight difference is that this is done once at the session establishment, the amount of information is limited, it does not interfere with routing information and it's optional. >> * Deployable today via already existing operating systems > > Really? I didn't know IOS knew how to write and send email. Last time I checked IOS you could pipe any output of a command to http cgi handler. The same basic mechanism can be used here. > Your email-based solution has an advantage over BGP advisory because of > message parsing? Wait, are we going to parse those NOC emails and do > something useful with them? If so, we better write a tool for that, > just like we would need one to parse information from the router syslog > messages or `show bgp neighbor`. If not, a human is going to have to > read those messages. How does your proposal have an advantage in either > parsing work or savings in man-hours vs the Scholl plan? I am not strongly suggesting email - it was just one example of out of band communication. I am just not seeing good fit to carry this inbound in BGP itself. Perhaps as suggested by Dave secure syslog to syslog channel is a good compromise ? In the email case you don't need to parse anything in real time. It can after basic validation end-up in syslog, netlog, bgplog etc - any database and just like you look in the syslog for BGP received message when needed to troubleshoot a problem just query in the exact same way for the event advisory msg received from the given peer. Now I am going to sit back, relax and watch how this thing evolves :) Cheers, R. From david.freedman@uk.clara.net Tue Mar 24 18:08:16 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0A03A6880 for ; Tue, 24 Mar 2009 18:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[AWL=3.197, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpBXjVnWe8vS for ; Tue, 24 Mar 2009 18:08:15 -0700 (PDT) Received: from staff01.mail.eu.clara.net (unknown [IPv6:2001:a88:0:fff7::54]) by core3.amsl.com (Postfix) with ESMTP id 2337E3A682A for ; Tue, 24 Mar 2009 18:08:14 -0700 (PDT) Received: from [192.168.201.202] (port=28231 helo=srvukfe02.claranet.local) by staff01.mail.eu.clara.net (staff01.mail.eu.clara.net [80.168.65.54]:25) with esmtp id 1LmHc9-0002EH-6D (Exim 4.69) for idr@ietf.org (return-path ); Wed, 25 Mar 2009 01:09:06 +0000 Received: from EXVS01.claranet.local ([192.168.201.205]) by srvukfe02.claranet.local with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 01:10:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ACE6.6BC472EA" Date: Wed, 25 Mar 2009 01:10:00 -0000 Message-ID: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD7F@EXVS01.claranet.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-scholl-idr-advisory-00 thread-index: Acms5mvBJPNdp7aaS5255b+H3/4rsA== From: "David Freedman" To: X-OriginalArrivalTime: 25 Mar 2009 01:10:00.0149 (UTC) FILETIME=[6B6C6050:01C9ACE6] X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:08:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ACE6.6BC472EA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >You want the router to write email to "4000" NOCs informing them of >pending maintenance? I'm pretty sure there are better tools available >for that. Sure, and it doesn't have to contact them all, the idea is to make this as configurable as possible such to both send_to and receive_from routers / messages of interest. > I like the idea that the same person who logs onto the router >o find out why a neighbor is down will have information about that >maintenance available in their log or `show bgp neighbor` output. You would think, but actually , most networks out there ignore such events if they are brief do not directly affect their customers (such as peerings which do not need to be used) > * No need to modify BGP protocol (only if at all as an option we >Unless you want those email addresses to be learnt from the BGP = neighbor >as you suggest. > * Deployable today via already existing operating systems >Really? I didn't know IOS knew how to write and send email. Sadly yes, it can :( http://blog.ioshints.info/2008/09/send-e-mail-after-router-reload.html > * No need to modify and parse anything at the potential 1000s of = peers. >Your email-based solution has an advantage over BGP advisory because of >message parsing? Wait, are we going to parse those NOC emails and do >something useful with them? If so, we better write a tool for that, >just like we would need one to parse information from the router syslog >messages or `show bgp neighbor`. If not, a human is going to have to >read those messages. How does your proposal have an advantage in = either >parsing work or savings in man-hours vs the Scholl plan? Look, the purpose of this is to provide information in-band with the session, if we want all communication to occur via email then fine, don't originate or accept any ADVISORY messages, the point being there are many operators out there who would like to see messages such as : - You are about to trip my max_prefix for your session (please hassle me into increasing it) - You are sending me lots of traffic which is failing some kind of policy / uRPF check ( you are a DoS source today ) - Our maintenance went wrong , Oops! we will be backing out the changes, expect session to flap again (saves public shaming) and countless other examples... Dave. ------------------------------------------------ David Freedman Group Network Engineering=20 Claranet Limited http://www.clara.net ------_=_NextPart_001_01C9ACE6.6BC472EA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: draft-scholl-idr-advisory-00

>You want the router to write email to = "4000" NOCs informing them of
>pending maintenance?  I'm pretty sure there are better tools = available
>for that.

Sure, and it doesn't have to contact them all, the idea is to make = this
as configurable
as possible such to both send_to and receive_from routers / messages = of
interest.

> I like the idea that the same person who logs onto the router
>o find out why a neighbor is down will have information about = that
>maintenance available in their log or `show bgp neighbor` = output.

You would think, but actually , most networks out there ignore such
events if they are brief
do not directly affect their customers (such as peerings which do = not
need to be used)

> * No need to modify BGP protocol (only if at all as an option = we
>Unless you want those email addresses to be learnt from the BGP = neighbor
>as you suggest.
> * Deployable today via already existing operating systems
>Really?  I didn't know IOS knew how to write and send = email.

Sadly yes, it can :(
http://blog.ioshints.info/2008/09/send-e-mail-after-router-reload.= html

> * No need to modify and parse anything at the potential 1000s of = peers.
>Your email-based solution has an advantage over BGP advisory because = of
>message parsing?  Wait, are we going to parse those NOC emails = and do
>something useful with them?  If so, we better write a tool for = that,
>just like we would need one to parse information from the router = syslog
>messages or `show bgp neighbor`.  If not, a human is going to = have to
>read those messages.  How does your proposal have an advantage = in either
>parsing work or savings in man-hours vs the Scholl plan?

Look, the purpose of this is to provide information in-band with the
session, if we want all communication to occur via email then fine,
don't originate or accept any ADVISORY messages,
the point being there are many operators out there who would like to = see
messages such as :

- You are about to trip my max_prefix for your session (please hassle = me
into increasing it)

- You are sending me lots of traffic which is failing some kind of
policy / uRPF check ( you are a DoS source today )

- Our maintenance went wrong , Oops! we will be backing out the = changes,
expect session to flap again (saves public shaming)

and countless other examples...

Dave.

------------------------------------------------
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net

------_=_NextPart_001_01C9ACE6.6BC472EA-- From danny@tcb.net Tue Mar 24 18:30:13 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3A5C28C15C for ; Tue, 24 Mar 2009 18:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyIOUC8f31JM for ; Tue, 24 Mar 2009 18:30:13 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 2139A28C19B for ; Tue, 24 Mar 2009 18:30:13 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id DFC8E2684EC; Tue, 24 Mar 2009 19:31:04 -0600 (MDT) Received: from sslvpn-109.ma.arbor.net (bedford.lex.arbor.net [204.118.128.2]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 24 Mar 2009 19:31:04 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: "SCHOLL, TOM (ATTLABS)" In-Reply-To: <22087C66F061B24EA008D146B7E9164304213778@gaalpa1msgusr73.ITServices.sbc.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 19:21:41 -0600 References: <22087C66F061B24EA008D146B7E9164304213778@gaalpa1msgusr73.ITServices.sbc.com> X-Mailer: Apple Mail (2.930.3) Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:30:13 -0000 On Mar 24, 2009, at 3:08 PM, SCHOLL, TOM (ATTLABS) wrote: > During the session yesterday, Dave Ward brought up that syslog was a > potentially viable option. Tom, I _think he was being facetious... -danny From dward@cisco.com Tue Mar 24 18:34:35 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889F83A6A64; Tue, 24 Mar 2009 18:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FswT73wbg5NZ; Tue, 24 Mar 2009 18:34:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B31E43A67D1; Tue, 24 Mar 2009 18:34:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,416,1233532800"; d="scan'208";a="146166173" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2009 01:35:26 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2P1ZQqf008385; Tue, 24 Mar 2009 18:35:26 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2P1ZMrY021394; Wed, 25 Mar 2009 01:35:26 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 21:35:16 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 21:35:15 -0400 Message-Id: From: David Ward To: Yakov Rekhter In-Reply-To: <200903250020.n2P0KZM68604@magenta.juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Mar 2009 20:35:13 -0500 References: <200903250020.n2P0KZM68604@magenta.juniper.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 25 Mar 2009 01:35:15.0246 (UTC) FILETIME=[F27DD4E0:01C9ACE9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=536; t=1237944926; x=1238808926; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[Idr]=20draft-ietf-idr-flow-spec |Sender:=20; bh=qdIVeG/k6Rtgjf8tub5bp/eRtyQFwUVfd2Or9sQDjS0=; b=SgIYmAdJovUgQG9qI4v7ifKb3vBpQigJ76GId4vCQIC5YiKW/Ogqf0HMd7 yE89KjlS9GvsFjRwpuwOGOGd1sfcUxgyZvS0z5Lc9CIhB7cFn/NuZQT3oTEh ZBUY6Tro/5; Authentication-Results: sj-dkim-4; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: idr@ietf.org, Sue Hares , David Ward , IESG IESG Subject: Re: [Idr] draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 01:34:35 -0000 Thanks for the note. There are still a number of open technical discuss items to deal with that must be addressed. -DWard On Mar 24, 2009, at 7:20 PM, Yakov Rekhter wrote: > Dave, > > Combination of comments received on the mailing list, and poll at > the IDR WG meeting indicates IDR WG consensus to ask IESG to advance > draft-ietf-idr-flow-spec to Proposed Standard. > > Yakov. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From pmohapat@cisco.com Tue Mar 24 22:08:40 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057EE3A6921 for ; Tue, 24 Mar 2009 22:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73JAURQSHJph for ; Tue, 24 Mar 2009 22:08:39 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4D92D3A690C for ; Tue, 24 Mar 2009 22:08:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,417,1233532800"; d="scan'208";a="68823617" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 25 Mar 2009 05:09:31 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2P59VbK010022 for ; Tue, 24 Mar 2009 22:09:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2P59VVm013063 for ; Wed, 25 Mar 2009 05:09:31 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 22:09:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 22:09:29 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408F2EAFC@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49C903E0.4070604@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: Acmsmddfx7svKaFWREKCuDcn6av5mQABOLdQ References: <49C903E0.4070604@raszuk.net> From: "Pradosh Mohapatra (pmohapat)" To: "idr" X-OriginalArrivalTime: 25 Mar 2009 05:09:30.0989 (UTC) FILETIME=[E11C89D0:01C9AD07] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=136; t=1237957771; x=1238821771; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20draft-rosen-idr-aigp-00.txt=20as=20IDR=20WG=20d ocument |Sender:=20; bh=wZE0s5uBZ9EIsLpquk8OSfAd6cZbJIEdGwHJ3lnS06U=; b=J/q3CkNn/TpjccixNDHV9kGlxYkELU2CxVkO98dI3C6vimKXl2UNIHUgKd fDDHV4kJ2EiaTOgadQO4dNlqypf/HglCCoIhCDY/OOSsm/NiQ0CwIdE1fT8W fcqx7/ZZwg; Authentication-Results: sj-dkim-3; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 05:08:40 -0000 The authors would like to request that draft-rosen-idr-aigp-00.txt be adopted as an IDR WG document. We presented it yesterday @ IDR. From dongjie_dj@huawei.com Wed Mar 25 01:13:04 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24FBA3A67FE for ; Wed, 25 Mar 2009 01:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYe+iTtZIVxJ for ; Wed, 25 Mar 2009 01:13:03 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4EF333A67FB for ; Wed, 25 Mar 2009 01:13:03 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KH100L6GYUWNY@szxga04-in.huawei.com> for idr@ietf.org; Wed, 25 Mar 2009 16:13:44 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KH100B0IYUWBY@szxga04-in.huawei.com> for idr@ietf.org; Wed, 25 Mar 2009 16:13:44 +0800 (CST) Received: from d65110 ([10.111.12.97]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KH1001J3YUV1F@szxml04-in.huawei.com> for idr@ietf.org; Wed, 25 Mar 2009 16:13:44 +0800 (CST) Date: Wed, 25 Mar 2009 16:13:43 +0800 From: Dong Jie In-reply-to: <49C93F90.5080403@raszuk.net> To: robert@raszuk.net, 'Richard A Steenbergen' Message-id: <008f01c9ad21$9d3f30e0$610c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmsvWwmHJ1egDGVRX2j7gxesa7AHgAXoZuQ Cc: 'idr' Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 08:13:04 -0000 Hi Robert and others, > I just don't see a benefit to use routing protocol (here BGP) to send an > SMS to a peering router when we know ahead of time that the router will > not do anything with it other then log to a syslog. Agreed. IMO, the concern is whether to send advisory messages in-band or out-band, and it should depend on the purpose of the message. If the message requires instant feedback of the peer, it should be sent in-band, and the peering router should have the capability to parse that message. If it's not this case, as Robert said, just some information to be logged, the message should be sent out-band, and stored somewhere, so the operators can check it when needed. > Nope .. as I indicated NOC info can be auto-negotiated inbound. I see no > reason why not. That would be just one new BGP capability as opposed to > new BGP message which will need to be parsed, which will take room of > your ever starving BGP IO input queues, which will keep real routing > information behind not too mention bgp keepalives etc ... Agreed. Best regards, Dong Jie From robert@raszuk.net Wed Mar 25 01:18:10 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E0C3A68B0 for ; Wed, 25 Mar 2009 01:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxUtY40ePz6y for ; Wed, 25 Mar 2009 01:18:10 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id D35F03A686D for ; Wed, 25 Mar 2009 01:18:09 -0700 (PDT) Received: (qmail 1875 invoked by uid 399); 25 Mar 2009 08:12:20 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.50.47) by mail37.opentransfer.com with SMTP; 25 Mar 2009 08:12:20 -0000 Message-ID: <49C9E761.904@raszuk.net> Date: Wed, 25 Mar 2009 01:12:17 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Ward References: <200903250020.n2P0KZM68604@magenta.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , Sue Hares , IESG IESG , idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 08:18:10 -0000 Hi David, Can you refresh co-authors and other WG members on the list of those open technical items ? As Yakov correctly pointed out during WG meeting other then IANA section update, few typos and new boiler plate there was no changes to the draft made after it passed previous last call. Cheers, R. > Thanks for the note. There are still a number of open technical discuss > items to deal with that must be addressed. > > -DWard > > On Mar 24, 2009, at 7:20 PM, Yakov Rekhter wrote: > >> Dave, >> >> Combination of comments received on the mailing list, and poll at >> the IDR WG meeting indicates IDR WG consensus to ask IESG to advance >> draft-ietf-idr-flow-spec to Proposed Standard. >> >> Yakov. >> From robert@raszuk.net Wed Mar 25 01:39:22 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313A33A6D08 for ; Wed, 25 Mar 2009 01:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87vQL9RxIGOq for ; Wed, 25 Mar 2009 01:39:21 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 3ACE33A6938 for ; Wed, 25 Mar 2009 01:39:21 -0700 (PDT) Received: (qmail 26971 invoked by uid 399); 25 Mar 2009 08:40:12 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.50.47) by mail37.opentransfer.com with SMTP; 25 Mar 2009 08:40:12 -0000 Message-ID: <49C9EDEA.6040002@raszuk.net> Date: Wed, 25 Mar 2009 01:40:10 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dong Jie References: <008f01c9ad21$9d3f30e0$610c6f0a@china.huawei.com> In-Reply-To: <008f01c9ad21$9d3f30e0$610c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'idr' Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 08:39:22 -0000 Hi Dong, Agreed ! There is in fact one observation I forgot to mention ... It seems perfectly feasible that some operators would like to allow to accept not all of such messages, but subset of them. If such message is sent in-band the practical filtering point would your BGP inbound policy. Do operators really want to add advisory free form text clauses into your real BGP inbound routing policy ? Aren't we already running today with issues about load associated with your BGP policy processing ? If we go along the lines of using BGP in-band do we also need to consider defining new ORF type for it ? Cheers, R. PS: IMHO procmail is a much more efficient tool then your favorite BGP regex policy engine in filtering for free form text. > Hi Robert and others, > >> I just don't see a benefit to use routing protocol (here BGP) to send an >> SMS to a peering router when we know ahead of time that the router will >> not do anything with it other then log to a syslog. > > Agreed. IMO, the concern is whether to send advisory messages in-band or > out-band, and it should depend on the purpose of the message. If the message > requires instant feedback of the peer, it should be sent in-band, and the > peering router should have the capability to parse that message. If it's not > this case, as Robert said, just some information to be logged, the message > should be sent out-band, and stored somewhere, so the operators can check it > when needed. > >> Nope .. as I indicated NOC info can be auto-negotiated inbound. I see no >> reason why not. That would be just one new BGP capability as opposed to >> new BGP message which will need to be parsed, which will take room of >> your ever starving BGP IO input queues, which will keep real routing >> information behind not too mention bgp keepalives etc ... > Agreed. > > Best regards, > Dong Jie From neil@domino.org Wed Mar 25 02:40:53 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0E83A6C17 for ; Wed, 25 Mar 2009 02:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKeSI4qHKP5o for ; Wed, 25 Mar 2009 02:40:52 -0700 (PDT) Received: from defiant.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by core3.amsl.com (Postfix) with ESMTP id 79ED33A6BC2 for ; Wed, 25 Mar 2009 02:40:52 -0700 (PDT) Received: from webmail2.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by defiant.domino.org (Postfix) with ESMTP id A7D93A6F8B; Wed, 25 Mar 2009 09:41:42 +0000 (GMT) Received: from 62.208.225.86 (proxying for 148.185.70.8) (SquirrelMail authenticated user neil) by webmail2.domino.org with HTTP; Wed, 25 Mar 2009 09:41:42 -0000 (GMT) Message-ID: <5880.62.208.225.86.1237974102.squirrel@webmail2.domino.org> In-Reply-To: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD7F@EXVS01.claranet.local> References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD7F@EXVS01.claranet.local> Date: Wed, 25 Mar 2009 09:41:42 -0000 (GMT) From: "Neil J. McRae" To: "David Freedman" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil@domino.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:40:53 -0000 David, > Look, the purpose of this is to provide information in-band with the > session, if we want all communication to occur via email then fine, > don't originate or accept any ADVISORY messages, > the point being there are many operators out there who would like to see > messages such as : It looks like we are trying to work around poor operational process by messing around with routing protocols. I can't see that being a scalable solution in the longer term, history has demonstrated that time and time again. Regards, Neil -- Neil J. McRae -- Alive and Kicking. neil@DOMINO.ORG From david.freedman@uk.clara.net Wed Mar 25 02:48:13 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C633A6970 for ; Wed, 25 Mar 2009 02:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.599, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw8mwLv2wrci for ; Wed, 25 Mar 2009 02:48:12 -0700 (PDT) Received: from staff01.mail.eu.clara.net (unknown [IPv6:2001:a88:0:fff7::54]) by core3.amsl.com (Postfix) with ESMTP id 7FE5F3A6938 for ; Wed, 25 Mar 2009 02:47:54 -0700 (PDT) Received: from [192.168.201.201] (port=14358 helo=srvukfe01.claranet.local) by staff01.mail.eu.clara.net (staff01.mail.eu.clara.net [80.168.65.54]:25) with esmtp id 1LmPj2-0000tp-52 (Exim 4.69) (return-path ); Wed, 25 Mar 2009 09:48:44 +0000 Received: from EXVS01.claranet.local ([192.168.201.205]) by srvukfe01.claranet.local with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 09:50:29 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AD2F.221EA924" Date: Wed, 25 Mar 2009 09:47:23 -0000 Message-ID: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD83@EXVS01.claranet.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-scholl-idr-advisory-00 thread-index: AcmtLj9Bb1XVYaavSauDpxVGYaZNWwAAHNTH References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD7F@EXVS01.claranet.local> <5880.62.208.225.86.1237974102.squirrel@webmail2.domino.org> From: "David Freedman" To: X-OriginalArrivalTime: 25 Mar 2009 09:50:29.0689 (UTC) FILETIME=[21AE0290:01C9AD2F] X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:48:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AD2F.221EA924 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm not seeing the point of this as replacing any operational=20 process at all, it is simply a tool to assist a human operator who has access to their own routers (either directly or via NMS = syslog/traps) I quite like the analogy of the path-trace buffer, if a human is looking = at it, it can cut down on troubleshooting time significantly. Dave.=20 ------------------------------------------------ David Freedman Group Network Engineering=20 Claranet Limited http://www.clara.net -----Original Message----- From: Neil J. McRae [mailto:neil@domino.org] Sent: Wed 3/25/2009 09:41 To: David Freedman Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 =20 David, > Look, the purpose of this is to provide information in-band with the > session, if we want all communication to occur via email then fine, > don't originate or accept any ADVISORY messages, > the point being there are many operators out there who would like to = see > messages such as : It looks like we are trying to work around poor operational process by messing around with routing protocols. I can't see that being a scalable solution in the longer term, history has demonstrated that time and time again. Regards, Neil -- Neil J. McRae -- Alive and Kicking. neil@DOMINO.ORG ------_=_NextPart_001_01C9AD2F.221EA924 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Idr] draft-scholl-idr-advisory-00

I'm not seeing the point of this as replacing any = operational
process at all, it is simply a tool to assist a human operator
who has access to their own routers (either directly or via NMS = syslog/traps)

I quite like the analogy of the path-trace buffer, if a human is looking = at it,
it can cut down on troubleshooting time significantly.

Dave.

------------------------------------------------
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net



-----Original Message-----
From: Neil J. McRae [mailto:neil@domino.org]
Sent: Wed 3/25/2009 09:41
To: David Freedman
Cc: idr@ietf.org
Subject: Re: [Idr] draft-scholl-idr-advisory-00

David,

> Look, the purpose of this is to provide information in-band with = the
> session, if we want all communication to occur via email then = fine,
> don't originate or accept any ADVISORY messages,
> the point being there are many operators out there who would like = to see
> messages such as :

It looks like we are trying to work around poor operational process = by
messing around with routing protocols. I can't see that being a = scalable
solution in the longer term, history has demonstrated that time and = time
again.

Regards,
Neil
--
Neil J. McRae -- Alive and Kicking.
neil@DOMINO.ORG

------_=_NextPart_001_01C9AD2F.221EA924-- From neil@domino.org Wed Mar 25 04:14:59 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31D93A68BE for ; Wed, 25 Mar 2009 04:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.284 X-Spam-Level: X-Spam-Status: No, score=0.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVUtt2NxAkI3 for ; Wed, 25 Mar 2009 04:14:58 -0700 (PDT) Received: from defiant.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by core3.amsl.com (Postfix) with ESMTP id C0E993A68B1 for ; Wed, 25 Mar 2009 04:14:58 -0700 (PDT) Received: from Inbox (unknown [149.254.48.23]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by defiant.domino.org (Postfix) with ESMTP id E0970A6C4A; Wed, 25 Mar 2009 11:15:47 +0000 (GMT) MIME-Version: 1.0 content-class: From: "Neil J. McRae" Date: Wed, 25 Mar 2009 11:15:46 +0000 Importance: normal X-Priority: 3 To: David Freedman Content-Type: multipart/alternative; boundary="_0AAB4A4B-75A0-7B25-051F-890FFC2AD789_" Message-Id: <20090325111547.E0970A6C4A@defiant.domino.org> Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 11:14:59 -0000 --_0AAB4A4B-75A0-7B25-051F-890FFC2AD789_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Im sure its that useful Dave but BGP is a routing protocol and I think by = bending it into this shape we just put most risk into routing infrastructur= e. Personally I'd prefer not to do that. -----Original Message----- From: David Freedman Sent: 25 March 2009 09:47 To: neil@domino.org Cc: idr@ietf.org Subject: RE: [Idr] draft-scholl-idr-advisory-00 I'm not seeing the point of this as replacing any operational process at all, it is simply a tool to assist a human operator who has access to their own routers (either directly or via NMS syslog/tra= ps) =20 I quite like the analogy of the path-trace buffer, if a human is looking a= t it, it can cut down on troubleshooting time significantly. =20 Dave. =20 ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net =20 =20 =20 -----Original Message----- From: Neil J. McRae [mailto:neil@domino.org] Sent: Wed 3/25/2009 09:41 To: David Freedman Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 =20 David, =20 > Look, the purpose of this is to provide information in-band with the > session, if we want all communication to occur via email then fine, > don't originate or accept any ADVISORY messages, > the point being there are many operators out there who would like to see > messages such as : =20 It looks like we are trying to work around poor operational process by messing around with routing protocols. I can't see that being a scalable solution in the longer term, history has demonstrated that time and time again. =20 Regards, Neil -- Neil J. McRae -- Alive and Kicking. neil@DOMINO.ORG =20 =20 =20 = --_0AAB4A4B-75A0-7B25-051F-890FFC2AD789_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" RE: [Idr] draft-scholl-idr-advisory-00Im sure its that useful Dave but BGP is a routing protocol and I think= by bending it into this shape we just put most risk into routing infrastru= cture. Personally I'd prefer not to do that.

From: David Fre= edman <david.freedman@uk.clara.net>
Sent: 25 March 2009 09:47
neil@domino.org
Cc: idr@ietf.org
Subject: RE: [Idr] dr= aft-scholl-idr-advisory-00

I'm not seeing= the point of this as replacing any operational
process at all, it is s= imply a tool to assist a human operator
who has access to their own rou= ters (either directly or via NMS syslog/traps)

I quite like the an= alogy of the path-trace buffer, if a human is looking at it,
it can cut= down on troubleshooting time significantly.

Dave.

------= ------------------------------------------
David Freedman
Group Net= work Engineering
Claranet Limited
= http://www.clara.net



-----Original Message-----
= From: Neil J. McRae [mailto:neil@domino.= org]
Sent: Wed 3/25/2009 09:41
To: David Freedman
Cc: idr@i= etf.org
Subject: Re: [Idr] draft-scholl-idr-advisory-00

David,=

> Look, the purpose of this is to provide information in-band = with the
> session, if we want all communication to occur via email = then fine,
> don't originate or accept any ADVISORY messages,
&g= t; the point being there are many operators out there who would like to see=
> messages such as :

It looks like we are trying to work a= round poor operational process by
messing around with routing protocols= I can't see that being a scalable
solution in the longer term, histor= y has demonstrated that time and time
again.

Regards,
Neil=
--
Neil J. McRae -- Alive and Kicking.
neil@DOMINO.ORG


= --_0AAB4A4B-75A0-7B25-051F-890FFC2AD789_-- From david.freedman@uk.clara.net Wed Mar 25 04:23:40 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626773A6894 for ; Wed, 25 Mar 2009 04:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.533 X-Spam-Level: X-Spam-Status: No, score=-1.533 tagged_above=-999 required=5 tests=[AWL=1.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6jgPlCwdci3 for ; Wed, 25 Mar 2009 04:23:39 -0700 (PDT) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id 7B7373A679F for ; Wed, 25 Mar 2009 04:23:39 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.69) (envelope-from ) id 1LmRDg-0004VZ-TT; Wed, 25 Mar 2009 11:24:28 +0000 Message-ID: <49CA146C.5020007@uk.clara.net> Date: Wed, 25 Mar 2009 11:24:28 +0000 From: David Freedman Organization: Claranet Limited User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "Neil J. McRae" References: <20090325111547.E0970A6C4A@defiant.domino.org> In-Reply-To: <20090325111547.E0970A6C4A@defiant.domino.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 11:23:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >Dave but BGP is a routing protocol and I think by bending it into this shape we But what is our alternative here, propose that NOTIFICATION no longer be terminal in all cases? The recent case of the transitive attributes has highlighted that we need a multi-pronged approach here , and whilst creating a type of non-terminal NOTIFICATION message (which would require significant code change and is counter-productive) , is not an option, ADVISORY seems like the next best thing. I'm happy with it, it is short and it is simple. If you don't want to send ADVISORY messages to me or allow me to send them to you, just don't negotiate the ADVISORY capability, which can be the vendor default position. Dave. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknKFGcACgkQtFWeqpgEZrKQnQCfXxto3R9mdcFaMV09ruWaDLKQ 4KMAoKS0IN2rmkSNNZNZtwY6D4sb03M6 =u1w+ -----END PGP SIGNATURE----- From rjs@eng.gxn.net Wed Mar 25 04:30:05 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48FC3A69AE for ; Wed, 25 Mar 2009 04:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y-1dWsK7IkU for ; Wed, 25 Mar 2009 04:30:05 -0700 (PDT) Received: from mx01.eng.pipex.net (mx01.eng.pipex.net [212.241.168.204]) by core3.amsl.com (Postfix) with ESMTP id 8E6293A679F for ; Wed, 25 Mar 2009 04:30:04 -0700 (PDT) Received: from bronze.eng.gxn.net (bronze.eng.gxn.net [212.241.168.68]) by mx01.eng.pipex.net (8.13.8/8.11.2) with ESMTP id n2PBUrPt005102; Wed, 25 Mar 2009 11:30:53 GMT X-Envelope-From: rjs@eng.gxn.net Received: (from rjs@localhost) by bronze.eng.gxn.net (8.13.1/8.13.1) id n2PBUq1W021048; Wed, 25 Mar 2009 11:30:52 GMT X-Authentication-Warning: bronze.eng.gxn.net: rjs set sender to rjs@eng.gxn.net using -f Date: Wed, 25 Mar 2009 11:30:52 +0000 From: Rob Shakir To: "Neil J. McRae" Message-ID: <20090325113052.GA29170@bronze.eng.gxn.net> References: <20090325111547.E0970A6C4A@defiant.domino.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090325111547.E0970A6C4A@defiant.domino.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mx01.eng.pipex.net [212.241.168.204]); Wed, 25 Mar 2009 11:30:53 +0000 (GMT) Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 11:30:06 -0000 On Wed, Mar 25, 2009 at 11:15:46AM +0000, Neil J. McRae wrote: > Im sure its that useful Dave but BGP is a routing protocol and I think by > bending it into this shape we just put most risk into routing infrastructure. > Personally I'd prefer not to do that. I agree that there is some scope for potential issues with the implementation of this idea, but I do not agree that a suggestion like this is putting 'most risk into routing infrastructure' - how is the risk that is added by implementing this capability any different to the risk imposed by adding any other new capability? I've discussed this with a number of operators, and feel that this extension would be extremely useful. As Dave says, this is not going to replace other communications between NOCs, but there are definitely a variety of deployments where this would be useful. If this protocol is adopted, I would urge against the RFC defining a set of standardised messages -- and rather leave this open to implementation. This then leaves some flexibility with operators and implementors to utilise this capability as required. I'd like to add my support to Tom's draft. Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html From elmi@detebe.org Wed Mar 25 05:10:51 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AADA3A6837 for ; Wed, 25 Mar 2009 05:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.588 X-Spam-Level: X-Spam-Status: No, score=-0.588 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kxru+EMqsbG for ; Wed, 25 Mar 2009 05:10:50 -0700 (PDT) Received: from ronin.4ever.de (elmi4711-1-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:1108::2]) by core3.amsl.com (Postfix) with ESMTP id 628CB3A6931 for ; Wed, 25 Mar 2009 05:10:50 -0700 (PDT) Received: from elmi by ronin.4ever.de with local (Exim 4.50 (FreeBSD)) id 1LmRxM-0003T5-T3; Wed, 25 Mar 2009 13:11:40 +0100 Date: Wed, 25 Mar 2009 13:11:40 +0100 From: "Elmar K. Bins" To: "Neil J. McRae" Message-ID: <20090325121140.GH74388@ronin.4ever.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.9i Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 12:25:49 -0000 (Sorry broke the headers on the first version...) neil@domino.org (Neil J. McRae) wrote: > Im sure its that useful Dave but BGP is a routing protocol and > I think by bending it into this shape we just put most risk into > routing infrastructure. Personally I'd prefer not to do that. I concur. Operational sloppiness should not be turned into the extension of a protocol that serves a defined signalling purpose. While it seems a nice idea being able to "chat" via BGP, it clutters the protocol with non BGP-related information _and_ adds another communication channel that operators need to check (unless the advisory message becomes mandatory attribute to every withdrawal or session shutdown; and then what happens when the peer simply goes away? Another channel to check...) The proposal says that this message "can speed up...by providing a direct correlation..." Well, this also means that all router gear has to store these messages. Typical implementation of this would be to syslog and forget them (memory is limited). The typical operator will then have that message mailed to her, and voil=E0 - either you're in our out of the loop, but an additional BGP attribute/message doesn't change that. I believe the proposal should be rejected due to not solving the problems inherent in operating networks. It should rather be used as a starting point for thinking about some better way for operators to communicate amongst themselves and towards interested parties where necessary. (Don't give your password to the press) I personally would like operators to use PeeringDB more, and implement some kind of "this location is down due to..." there. Yours, Elmar. From dward@cisco.com Wed Mar 25 06:19:19 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36033A6B76; Wed, 25 Mar 2009 06:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQgVMA5doJhS; Wed, 25 Mar 2009 06:19:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BF0083A6B6A; Wed, 25 Mar 2009 06:19:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,419,1233532800"; d="scan'208";a="161353167" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 25 Mar 2009 13:20:11 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2PDKBQ7014955; Wed, 25 Mar 2009 06:20:11 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2PDJwpl017012; Wed, 25 Mar 2009 13:20:11 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 09:19:59 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 09:19:59 -0400 Message-Id: <74D25FAD-A175-47A5-95D6-FCD6F3157A79@cisco.com> From: David Ward To: robert@raszuk.net In-Reply-To: <49C9E761.904@raszuk.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 08:19:57 -0500 References: <200903250020.n2P0KZM68604@magenta.juniper.net> <49C9E761.904@raszuk.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 25 Mar 2009 13:19:59.0122 (UTC) FILETIME=[65A54720:01C9AD4C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=871; t=1237987211; x=1238851211; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[Idr]=20draft-ietf-idr-flow-spec |Sender:=20; bh=KUnDMB2fK07u+2J6YOQXzoD1GDHa7mYixyFMUkACFnc=; b=MTS3ZBzdQEUAdRJZLpbvXI5IaG+SVsLZcAGuP7k0IKEz43UVnY4rQWUCwO ehcJFfSW4Spak7cmnpty+TRcrRksLnTN/fc+zlO/v3DRq5flQ6T62NxUm8J1 QUbBJ7+P3h; Authentication-Results: sj-dkim-3; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IESG IESG , Yakov Rekhter , Sue Hares , David Ward , idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 13:19:19 -0000 There is a long list in the tracker. -DWard On Mar 25, 2009, at 3:12 AM, Robert Raszuk wrote: > Hi David, > > Can you refresh co-authors and other WG members on the list of those > open technical items ? > > As Yakov correctly pointed out during WG meeting other then IANA > section update, few typos and new boiler plate there was no changes > to the draft made after it passed previous last call. > > Cheers, > R. > >> Thanks for the note. There are still a number of open technical >> discuss items to deal with that must be addressed. >> -DWard >> On Mar 24, 2009, at 7:20 PM, Yakov Rekhter wrote: >>> Dave, >>> >>> Combination of comments received on the mailing list, and poll at >>> the IDR WG meeting indicates IDR WG consensus to ask IESG to advance >>> draft-ietf-idr-flow-spec to Proposed Standard. >>> >>> Yakov. >>> From yakov@juniper.net Wed Mar 25 07:06:34 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886BF3A6A42 for ; Wed, 25 Mar 2009 07:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgmjkWQiMUvk for ; Wed, 25 Mar 2009 07:06:33 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id D1D863A693E for ; Wed, 25 Mar 2009 07:06:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSco6nbwYwBoltLmhwAMAhL6Oo71479E5@postini.com; Wed, 25 Mar 2009 07:07:26 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Wed, 25 Mar 2009 06:51:29 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 06:51:29 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 06:51:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 06:51:28 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2PDpSM90637 for ; Wed, 25 Mar 2009 06:51:28 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903251351.n2PDpSM90637@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93274.1237989088.1@juniper.net> Date: Wed, 25 Mar 2009 06:51:28 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 25 Mar 2009 13:51:28.0409 (UTC) FILETIME=[CBBF9890:01C9AD50] Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 14:06:34 -0000 Folks, We received a request to accept draft-rosen-idr-aigp-00.txt as an IDR WG document. The deadline for comments on this request is April 8, 2009. If anyone is aware of the IPR related to the draft, please follow the procedurs of rfc3979. Yakov. ------- Forwarded Message Date: Tue, 24 Mar 2009 22:09:29 -0700 From: "Pradosh Mohapatra (pmohapat)" To: "idr" Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document The authors would like to request that draft-rosen-idr-aigp-00.txt be adopted as an IDR WG document. We presented it yesterday @ IDR. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message From tony.li@tony.li Wed Mar 25 07:16:39 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DDF3A68B8 for ; Wed, 25 Mar 2009 07:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H78FXB2sqFTG for ; Wed, 25 Mar 2009 07:16:38 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 95C973A690A for ; Wed, 25 Mar 2009 07:16:38 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id XPPh1b0030lTkoCA1SH9cH; Wed, 25 Mar 2009 14:17:09 +0000 Received: from [127.0.0.1] ([130.129.65.195]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id XSGu1b00k4ClyMu8QSHCGp; Wed, 25 Mar 2009 14:17:27 +0000 Message-ID: <49CA3C98.9020208@tony.li> Date: Wed, 25 Mar 2009 07:15:52 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Ward References: <200903250020.n2P0KZM68604@magenta.juniper.net> <49C9E761.904@raszuk.net> <74D25FAD-A175-47A5-95D6-FCD6F3157A79@cisco.com> In-Reply-To: <74D25FAD-A175-47A5-95D6-FCD6F3157A79@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , Sue Hares , IESG IESG , idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-flow-spec X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 14:16:39 -0000 David Ward wrote: > There is a long list in the tracker. Evaluation for draft-ietf-idr-flow-spec-05.txt can be found at https://datatracker.ietf.org/idtracker/ballot/2997/ Tony From zali@cisco.com Wed Mar 25 07:26:41 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC53F28C0D7 for ; Wed, 25 Mar 2009 07:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpn1QMaEuMp7 for ; Wed, 25 Mar 2009 07:26:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E743428C0E9 for ; Wed, 25 Mar 2009 07:26:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,419,1233532800"; d="scan'208";a="273856150" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 25 Mar 2009 14:27:33 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2PERWTw025335; Wed, 25 Mar 2009 10:27:32 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2PERW0h003037; Wed, 25 Mar 2009 14:27:32 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 10:27:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 10:27:05 -0400 Message-ID: In-Reply-To: <200903251351.n2PDpSM90637@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcmtUw+vaYnEMnPHTs2w6fRSR6KVRAAApQwg References: <200903251351.n2PDpSM90637@magenta.juniper.net> From: "Zafar Ali (zali)" To: "Yakov Rekhter" , X-OriginalArrivalTime: 25 Mar 2009 14:27:32.0696 (UTC) FILETIME=[D5C39580:01C9AD55] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1318; t=1237991252; x=1238855252; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20(zali)=22=20 |Subject:=20RE=3A=20[Idr]=20=20draft-rosen-idr-aigp-00.txt= 20as=20IDR=20WG=20document |Sender:=20 |To:=20=22Yakov=20Rekhter=22=20,=20; bh=y91dBT4ydac/8xZ2rIr47IAELvtzIYxYg7BOA7MAfrU=; b=EWhjZ4dEoojsISlAv80d0tdvcfP87Uro0db0zqnHJXtne4ZtiE2iIhjQ52 hRn0c1ZvmAkl5tXGuve6M+PiGlW0HI8MnI0egJNCQfSyNGGHziaAEyLoQYVv RZDBJDzWFL; Authentication-Results: rtp-dkim-2; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 14:26:41 -0000 In Favor.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > Behalf Of Yakov Rekhter > Sent: Wednesday, March 25, 2009 9:51 AM > To: idr@ietf.org > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document >=20 > Folks, >=20 > We received a request to accept draft-rosen-idr-aigp-00.txt=20 > as an IDR WG document. The deadline for comments on this=20 > request is April 8, 2009. >=20 > If anyone is aware of the IPR related to the draft, please=20 > follow the procedurs of rfc3979. >=20 > Yakov. > ------- Forwarded Message >=20 > Date: Tue, 24 Mar 2009 22:09:29 -0700 > From: "Pradosh Mohapatra (pmohapat)" > To: "idr" > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document >=20 > The authors would like to request that=20 > draft-rosen-idr-aigp-00.txt be adopted as an IDR WG document.=20 > We presented it yesterday @ IDR. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From ts3127@att.com Wed Mar 25 07:53:24 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F1F3A68F6 for ; Wed, 25 Mar 2009 07:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXFItjoVia+W for ; Wed, 25 Mar 2009 07:53:23 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 5DE993A6811 for ; Wed, 25 Mar 2009 07:53:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ts3127@att.com X-Msg-Ref: server-11.tower-129.messagelabs.com!1237992854!4650361!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 8921 invoked from network); 25 Mar 2009 14:54:15 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-11.tower-129.messagelabs.com with AES256-SHA encrypted SMTP; 25 Mar 2009 14:54:15 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n2PEsD8e002253; Wed, 25 Mar 2009 09:54:14 -0500 Received: from gaalpa1msghub80.ITServices.sbc.com (gaalpa1msghub80.itservices.sbc.com [135.53.26.20]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n2PEsA0F002204; Wed, 25 Mar 2009 09:54:10 -0500 Received: from gaalpa1msgusr73.ITServices.sbc.com ([135.53.8.26]) by gaalpa1msghub80.ITServices.sbc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 10:54:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 10:55:44 -0400 Message-ID: <22087C66F061B24EA008D146B7E9164304213971@gaalpa1msgusr73.ITServices.sbc.com> In-Reply-To: <20090325121140.GH74388@ronin.4ever.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-scholl-idr-advisory-00 Thread-Index: AcmtRPvNV7tjHOIwSGGjlsppW/8PTAAE+T1Q From: "SCHOLL, TOM (ATTLABS)" To: "Elmar K. Bins" , "Neil J. McRae" X-OriginalArrivalTime: 25 Mar 2009 14:54:09.0579 (UTC) FILETIME=[8D9497B0:01C9AD59] X-TM-AS-Product-Ver: SMEX-7.0.0.1607-5.6.1016-16540.007 X-TM-AS-Result: No--17.131700-0.000000-31 Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 14:53:24 -0000 > > Im sure its that useful Dave but BGP is a routing protocol and > > I think by bending it into this shape we just put most risk into > > routing infrastructure. Personally I'd prefer not to do that. >=20 > I concur. Operational sloppiness should not be turned into the > extension of a protocol that serves a defined signalling purpose. What if mail servers are offline/unreachable at either end? What if the IX operations mailing list is down? > While it seems a nice idea being able to "chat" via BGP, it > clutters the protocol with non BGP-related information _and_ > adds another communication channel that operators need to check > (unless the advisory message becomes mandatory attribute to > every withdrawal or session shutdown; and then what happens > when the peer simply goes away? Another channel to check...) For some parties, checking the router is the first place to check. When you notice traffic change on graphs, some individuals go to check on the router to find out why. When customers complain about a path change from observing traceroutes, someone is going to login to a router to determine why they're not going through the previous path. > I personally would like operators to use PeeringDB more, and > implement some kind of "this location is down due to..." there. What if PeeringDB has a disk failure or is unreachable? From elmi@detebe.org Wed Mar 25 08:12:04 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BEC63A69E0 for ; Wed, 25 Mar 2009 08:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQwe84VSsZZ8 for ; Wed, 25 Mar 2009 08:12:03 -0700 (PDT) Received: from ronin.4ever.de (elmi4711-1-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:1108::2]) by core3.amsl.com (Postfix) with ESMTP id 2A4FD3A6802 for ; Wed, 25 Mar 2009 08:12:03 -0700 (PDT) Received: from elmi by ronin.4ever.de with local (Exim 4.50 (FreeBSD)) id 1LmUmk-000CQj-1I; Wed, 25 Mar 2009 16:12:54 +0100 Date: Wed, 25 Mar 2009 16:12:54 +0100 From: "Elmar K. Bins" To: "SCHOLL, TOM (ATTLABS)" Message-ID: <20090325151253.GN74388@ronin.4ever.de> References: <20090325121140.GH74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E9164304213971@gaalpa1msgusr73.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22087C66F061B24EA008D146B7E9164304213971@gaalpa1msgusr73.ITServices.sbc.com> Organization: unorganized since 1789 X-Whisky: Knockando, extra old reserve X-Ncc-RegID: de.denic User-Agent: Mutt/1.5.9i Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:12:04 -0000 Re Tom, ts3127@att.com (SCHOLL, TOM (ATTLABS)) wrote: > > I concur. Operational sloppiness should not be turned into the > > extension of a protocol that serves a defined signalling purpose. > > What if mail servers are offline/unreachable at either end? What if the > IX operations mailing list is down? What if the syslog snippet has been mailed to you, but your mail server is offline/unreachable? What if your logging buffer on the router is only 4/8/16/...KBytes and that message has scrolled off? (Meaning: Where's the difference?) > For some parties, checking the router is the first place to check. When > you notice traffic change on graphs, some individuals go to check on the > router to find out why. When customers complain about a path change from > observing traceroutes, someone is going to login to a router to > determine why they're not going through the previous path. If my alerting system hasn't already told me which BGP session has gone down, and if my mailbox doesn't hold anything from the peer in question, I'll check the router. But: If my NOC works ok/good, they (or I) know about the failure due to advance notice. If my NOC doesn't work ok/good, they will not bother checking the router. So your point is: If I for whatever reason missed the email, _AND_ this is a scheduled outage, _THEN_ the message would help me. There will be no improvement if this is _not_ a scheduled outage or if I read my emails (provided the other party can write that warning email, which is pretty likely if it's a scheduled outage). Well, as I wrote before: Usually, logging buffers on routers are kept (too) small and have to contain (too) many messages, so practicality demands that this message too should go through syslog and the usual filtering/alerting process. If your alerting system (usually it is email or email-to-sms, if we're truthful about it) is down, you won't get either message. Were this feature implemented in a way that would - store the (last) message in the BGP neighbour's info - display that message in "show * neighbor xxx" output _then_ this would be helpful. Otherwise there would be no improvement. Basing a protocol upon implementation specifics, because it would be useless if implemented in another way...? See, I am lazy as well, so if I could just say "router bgp xxxx neighbor * message ---Scheduled outage from 1500 to 1730---" and I could be certain my peers knew what was about to happen, I'd like that, too. Still I prefer to write an outage email if I expect multiple session drops or an extended outage. Then there's the matter of security issues in implementation and usage (abuse, buffer overflows, buggy implementation, ...) > > I personally would like operators to use PeeringDB more, and > > implement some kind of "this location is down due to..." there. > > What if PeeringDB has a disk failure or is unreachable? What if it snows in summer? It can happen. In that case you're screwed (or rather: uninformed), just like if you didn't see the message scrolling by in your syslog or you broke your alerting system. Honestly, getting operational messages across is a pretty good idea, yet I don't see this in a standardised routing protocol. Yours, Elmi. PS: Anyone thought of character sets and encoding? Anyone want to go Kanji or chinese script about this? From ras@gerbil.cluepon.net Wed Mar 25 08:28:03 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710CB28C136 for ; Wed, 25 Mar 2009 08:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iIWccNDrGM3 for ; Wed, 25 Mar 2009 08:28:02 -0700 (PDT) Received: from gerbil.cluepon.net (e-gerbil.net [69.31.1.2]) by core3.amsl.com (Postfix) with ESMTP id BF20D28C10F for ; Wed, 25 Mar 2009 08:27:45 -0700 (PDT) Received: from gerbil.cluepon.net (ras@localhost [127.0.0.1]) by gerbil.cluepon.net (8.14.3/8.14.3) with ESMTP id n2PFSZV9092931; Wed, 25 Mar 2009 10:28:35 -0500 (CDT) (envelope-from ras@gerbil.cluepon.net) Received: (from ras@localhost) by gerbil.cluepon.net (8.14.3/8.14.3/Submit) id n2PFSYV9092930; Wed, 25 Mar 2009 10:28:34 -0500 (CDT) (envelope-from ras) Date: Wed, 25 Mar 2009 10:28:34 -0500 From: Richard A Steenbergen To: "Neil J. McRae" Message-ID: <20090325152834.GQ51443@gerbil.cluepon.net> References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD7F@EXVS01.claranet.local> <5880.62.208.225.86.1237974102.squirrel@webmail2.domino.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5880.62.208.225.86.1237974102.squirrel@webmail2.domino.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:28:03 -0000 On Wed, Mar 25, 2009 at 09:41:42AM -0000, Neil J. McRae wrote: > It looks like we are trying to work around poor operational process by > messing around with routing protocols. I can't see that being a scalable > solution in the longer term, history has demonstrated that time and time > again. It seems like your objection is purely theoretical, with no evidence of any practical problems at all. Please explain to me, in specific terms, how sending one extra small message which does not propagate or replicate inside an already established BGP session "does not scale"? -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From robert@raszuk.net Wed Mar 25 08:29:06 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33CD28C198 for ; Wed, 25 Mar 2009 08:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSiaG8AL1HuF for ; Wed, 25 Mar 2009 08:29:05 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id BD03B28C111 for ; Wed, 25 Mar 2009 08:29:05 -0700 (PDT) Received: (qmail 32569 invoked by uid 399); 25 Mar 2009 15:29:57 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.240.237) by mail37.opentransfer.com with SMTP; 25 Mar 2009 15:29:57 -0000 Message-ID: <49CA4DF1.1030108@raszuk.net> Date: Wed, 25 Mar 2009 08:29:53 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "SCHOLL, TOM (ATTLABS)" References: <22087C66F061B24EA008D146B7E9164304213971@gaalpa1msgusr73.ITServices.sbc.com> In-Reply-To: <22087C66F061B24EA008D146B7E9164304213971@gaalpa1msgusr73.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Freedman , idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:29:06 -0000 Tom, How big buffer of those messages you would like to store at the router ? When you are logged in you can browse syslog which is most likely at NOC. It is just an illusion that the info is local while it is physically far away or worse distributed in chunks across 100+ hard drives. Let's just don't fall into an old grandmamma's fear that if the money are not in her purse - deep in the pocket then no matter how much she has in her bank account she feels broke & poor. In fact contrary I think that just keep such info locally and not sharing it (at least) intra-domain is an issue .. perhaps your colleague from other NOC in Asia is troubleshooting a problem and while logged into ASBR in his jurisdiction wants to grep by given timestamp all syslog messages. If the info is just local it will not be visible. Cheers, R. >>> Im sure its that useful Dave but BGP is a routing protocol and >>> I think by bending it into this shape we just put most risk into >>> routing infrastructure. Personally I'd prefer not to do that. >> I concur. Operational sloppiness should not be turned into the >> extension of a protocol that serves a defined signalling purpose. > > What if mail servers are offline/unreachable at either end? What if the > IX operations mailing list is down? > >> While it seems a nice idea being able to "chat" via BGP, it >> clutters the protocol with non BGP-related information _and_ >> adds another communication channel that operators need to check >> (unless the advisory message becomes mandatory attribute to >> every withdrawal or session shutdown; and then what happens >> when the peer simply goes away? Another channel to check...) > > For some parties, checking the router is the first place to check. When > you notice traffic change on graphs, some individuals go to check on the > router to find out why. When customers complain about a path change from > observing traceroutes, someone is going to login to a router to > determine why they're not going through the previous path. > >> I personally would like operators to use PeeringDB more, and >> implement some kind of "this location is down due to..." there. > > What if PeeringDB has a disk failure or is unreachable? > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From erosen@cisco.com Wed Mar 25 08:31:48 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D2628C108 for ; Wed, 25 Mar 2009 08:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpI4PhByPIFZ for ; Wed, 25 Mar 2009 08:31:47 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8E75528C111 for ; Wed, 25 Mar 2009 08:31:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,419,1233532800"; d="scan'208";a="161423959" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 25 Mar 2009 15:32:39 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2PFWdCL024589; Wed, 25 Mar 2009 11:32:39 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2PFWdd0011452; Wed, 25 Mar 2009 15:32:39 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n2PFWcOP022320; Wed, 25 Mar 2009 11:32:38 -0400 To: "Seely, Ted A [CTO]" In-reply-to: Your message of Tue, 24 Mar 2009 14:43:22 -0500. Date: Wed, 25 Mar 2009 11:32:38 -0400 Message-ID: <22319.1237995158@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1485; t=1237995159; x=1238859159; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20[Idr]=20draft-scholl-idr-advisory-00=20 |Sender:=20 |To:=20=22Seely,=20Ted=20A=20[CTO]=22=20; bh=J3rcBPMNYeMnpqr0ypt87+Wx95rwGBUbWutVdiePSPQ=; b=WBzrSufidsS9hHG8/ZSeaZglyMJTM5yN3Z7LHnV+zJu1BFpMfFxTTBCXyc wcZrgzic2pD0oYFN89gsdV7MWjWRhX2tnFcjfHrRauFktOwKyzs60gmaF7Qm 2JhIw26IiT; Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2009 15:31:48 -0000 Without taking a position on this draft, I would like to make a comment. > I agree that structured messages certainly have their place ... but I > don't think this replaces the benefits of a free-form text message There are protocols that convey errors and/or advisory notices in free-from text messages. SMTP is one prominent example. The result is that for every condition of note, there are dozens of possible text strings you might get. Further, the identical text string from two different implementations might mean two completely different things. Not only that, the text string might be in a language not understood by the recipient, or even in a language that can't be meaningfully displayed at the receiving end. There's also the prospect of text strings which do not accurately describe the condition that elicited them. E.g., ever have a browser tell you "cannot contact host" when the problem is that the local DNS resolver is down? > Certainly every network operator I've talked to has all but jumped for joy > at the prospect of having this functionality All I can say is that when I was managing a large international mailing list, I would have jumped for joy at the prospect of eliminating the SMTP text strings in favor of a set of well-defined error codes ;-) So I tend to think that getting real utility out of a free-form text capability is not as straightforward as it seems. From ts3127@att.com Wed Mar 25 08:33:15 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0C528C1FF for ; Wed, 25 Mar 2009 08:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.278 X-Spam-Level: X-Spam-Status: No, score=-106.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AEXYhv3Pn20 for ; Wed, 25 Mar 2009 08:33:15 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 0293628C1F2 for ; Wed, 25 Mar 2009 08:33:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ts3127@att.com X-Msg-Ref: server-13.tower-161.messagelabs.com!1237995246!14862285!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.112.25] Received: (qmail 1969 invoked from network); 25 Mar 2009 15:34:06 -0000 Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-13.tower-161.messagelabs.com with AES256-SHA encrypted SMTP; 25 Mar 2009 15:34:06 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n2PFY5YJ024270; Wed, 25 Mar 2009 10:34:05 -0500 Received: from gaalpa1msghub80.ITServices.sbc.com (gaalpa1msghub80.itservices.sbc.com [135.53.26.20]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id n2PFXx5I024132; Wed, 25 Mar 2009 10:33:59 -0500 Received: from gaalpa1msgusr73.ITServices.sbc.com ([135.53.8.26]) by gaalpa1msghub80.ITServices.sbc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 11:33:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 11:35:35 -0400 Message-ID: <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> In-Reply-To: <20090325151253.GN74388@ronin.4ever.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-scholl-idr-advisory-00 Thread-Index: AcmtXDK9dWtt/wLjRNWVlAvQ44ecdwAAFkIQ From: "SCHOLL, TOM (ATTLABS)" To: "Elmar K. Bins" X-OriginalArrivalTime: 25 Mar 2009 15:33:58.0531 (UTC) FILETIME=[1D81BD30:01C9AD5F] X-TM-AS-Product-Ver: SMEX-7.0.0.1607-5.6.1016-16540.007 X-TM-AS-Result: No--1.952100-0.000000-31 Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:33:15 -0000 > Were this feature implemented in a way that would >=20 > - store the (last) message in the BGP neighbour's info > - display that message in "show * neighbor xxx" output >=20 > _then_ this would be helpful. Otherwise there would be no > improvement. Basing a protocol upon implementation specifics, > because it would be useless if implemented in another way...? In the slides I presented, initial feedback included a request to have the equivalent of a "sticky" message. This would transmit to a neighbor and would be visible via "show bgp nei " output. Are you saying that you'd agree with this functionality? From mschmidt@equinix.com Wed Mar 25 08:51:58 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFF73A6B72 for ; Wed, 25 Mar 2009 08:51:58 -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=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiGwXtmRFJhu for ; Wed, 25 Mar 2009 08:51:57 -0700 (PDT) Received: from smtpobhost.equinix.net (smtpobhost.equinix.net [207.20.85.100]) by core3.amsl.com (Postfix) with ESMTP id 324B93A6B36 for ; Wed, 25 Mar 2009 08:51:57 -0700 (PDT) Received: from glaciar.corp.equinix.com (mschmidt1-test.sv3.corp.equinix.com [172.22.28.245] (may be forged)) by prod107.corp.equinix.com (8.14.3/8.14.3) with ESMTP id n2PFqmMb015820; Wed, 25 Mar 2009 08:52:48 -0700 (PDT) Received: from glaciar.corp.equinix.com (localhost [127.0.0.1]) by glaciar.corp.equinix.com (8.12.11/8.12.11) with ESMTP id n2PFqlOA005552; Wed, 25 Mar 2009 08:52:47 -0700 (PDT) Received: (from mschmidt@localhost) by glaciar.corp.equinix.com (8.12.11/8.12.11) id n2PFqllC017129; Wed, 25 Mar 2009 08:52:47 -0700 (PDT) Date: Wed, 25 Mar 2009 08:52:47 -0700 From: Marcelo Schmidt To: Eric Rosen Message-ID: <20090325155247.GB18430@equinix.com> References: <22319.1237995158@erosen-linux> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: <22319.1237995158@erosen-linux> User-Agent: Mutt/1.4.2.1i Cc: idr , "Seely, Ted A \[CTO\]" Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:51:58 -0000 --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I support this comment. The technical issues we are discussing in this=20 advisory draft were discussed and some of them resolved in SNMP, STMP, SIP,= =20 HTTP, IRC, etc. If with all these other tools plus the legacy of phone=20 lines we cannot communicate better, then the problem is not going to be=20 solved by adding a new type of message. I think we have enough tools but= =20 we lack of a standardization in the language we use to communicate events. = =20 If we can define a draft with these standardization first, then we could=20 revisit the delivery method again IMHO. -m On Wed, Mar 25, 2009 at 08:32:38AM -0700, Eric Rosen wrote: >=20 > Without taking a position on this draft, I would like to make a > comment. > > I agree that structured messages certainly have their place ... > but I > > don't think this replaces the benefits of a free-form text message > There are protocols that convey errors and/or advisory notices in > free-from > text messages. SMTP is one prominent example. > The result is that for every condition of note, there are dozens of > possible > text strings you might get. Further, the identical text string > from two > different implementations might mean two completely different > things. Not > only that, the text string might be in a language not understood > by the > recipient, or even in a language that can't be meaningfully displayed > at the > receiving end. > There's also the prospect of text strings which do not accurately > describe > the condition that elicited them. E.g., ever have a browser > tell you > "cannot contact host" when the problem is that the local DNS > resolver is > down? > > Certainly every network operator I've talked to has all but jumped > for joy > > at the prospect of having this functionality > All I can say is that when I was managing a large international > mailing > list, I would have jumped for joy at the prospect of eliminating > the SMTP > text strings in favor of a set of well-defined error codes ;-) > So I tend to think that getting real utility out of a > free-form text > capability is not as straightforward as it seems. > _______________________________________________ > Idr mailing list > Idr@ietf.org > [1]https://www.ietf.org/mailman/listinfo/idr >=20 > References >=20 > 1. https://www.ietf.org/mailman/listinfo/idr --=20 -m =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Key fingerprint =3D 8E48 6CD0 6D2B 538E 264B D1D0 21E2 E7EE A40F 2A0B gpg --keyserver wwwkeys.pgp.net --recv-keys 0xA40F2A0B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iD8DBQFJylNPIeLn7qQPKgsRAuWZAJwLMisdUxd3jrAaUs9aqfBkXomY7gCdGiBY jsjPCuL1U4kWeuUFgZCw/tg= =8ZHS -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From robert@raszuk.net Wed Mar 25 08:57:28 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3E53A6BB8 for ; Wed, 25 Mar 2009 08:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxrNcXeaxjU5 for ; Wed, 25 Mar 2009 08:57:27 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 4870628C16C for ; Wed, 25 Mar 2009 08:57:27 -0700 (PDT) Received: (qmail 27448 invoked by uid 399); 25 Mar 2009 15:58:19 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.240.237) by mail37.opentransfer.com with SMTP; 25 Mar 2009 15:58:19 -0000 Message-ID: <49CA5497.7070107@raszuk.net> Date: Wed, 25 Mar 2009 08:58:15 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Richard A Steenbergen References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD7F@EXVS01.claranet.local> <5880.62.208.225.86.1237974102.squirrel@webmail2.domino.org> <20090325152834.GQ51443@gerbil.cluepon.net> In-Reply-To: <20090325152834.GQ51443@gerbil.cluepon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:57:28 -0000 Hi Richard, > how sending one extra small message Talking about size ... is 140 bytes good enough ? Why not 150 bytes or 1500 or max BGP PDU ? Perhaps instead it would be good idea to just send a URL pointer in such message which can easily be text retrievable. More over if modification to original warning is made it would not need to result in next message. The same for prefix limit threshold ... if I am customer with 10000 branch locations and you are signaling on some peering points that prefix limit is reached how good is this for my low cost branch router to get such data as opposed to my head quarter's 24x7 NOC ? Are we back to enforcing this to go via the same network from branch to a syslog at the NOC ? Is this one message per day, per hour or per second ? The draft says that implementation must limit the rate, but does not say to what value. It is just Speed Limit sign on the road without the value :) In the steady state (well there is never a steady state in BGP but let's leave it) perhaps you could get this through just fine. But the same tool should be supposedly used also for event driven notifications. Those will be likely correlated with increase of routing information. If both are over the same BGP session I see no easy way of making sure there is no interaction between them. Another point is why limit it just to your peer ? If I am an AS planning for AS number migration I would like to tell all of my AS peers about perhaps with AS-PATHLIMIT perimeter of 2. Just in case their NOC would be aware about my plans to mess with AS numbers which if not carefully planned may result in major traffic pattern shift. I don't think this tool will allow you this. Last .. why just limit to ASCII string no matter in what character encoding ? What happens if tomorrow NASDAQ comes to IDR and says ... I hear you guys have a nice global protocol ... We will pay you operators and you vendors a lot if you just allow one new message type to send stock info globally with it .... we already heard you are using it for sending p2p text messages between yourself with it. Cheers, R. > On Wed, Mar 25, 2009 at 09:41:42AM -0000, Neil J. McRae wrote: >> It looks like we are trying to work around poor operational process by >> messing around with routing protocols. I can't see that being a scalable >> solution in the longer term, history has demonstrated that time and time >> again. > > It seems like your objection is purely theoretical, with no evidence of > any practical problems at all. Please explain to me, in specific terms, > how sending one extra small message which does not propagate or > replicate inside an already established BGP session "does not scale"? > From neil@domino.org Wed Mar 25 08:58:20 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82FE3A67EA for ; Wed, 25 Mar 2009 08:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMieOKYmCXOV for ; Wed, 25 Mar 2009 08:58:20 -0700 (PDT) Received: from defiant.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by core3.amsl.com (Postfix) with ESMTP id 7B97C3A6869 for ; Wed, 25 Mar 2009 08:58:07 -0700 (PDT) Received: from webmail2.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by defiant.domino.org (Postfix) with ESMTP id AD233A6F9F; Wed, 25 Mar 2009 15:58:58 +0000 (GMT) Received: from 62.208.225.86 (proxying for 148.185.70.8) (SquirrelMail authenticated user neil) by webmail2.domino.org with HTTP; Wed, 25 Mar 2009 15:58:58 -0000 (GMT) Message-ID: <21626.62.208.225.86.1237996738.squirrel@webmail2.domino.org> In-Reply-To: <20090325152834.GQ51443@gerbil.cluepon.net> References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD7F@EXVS01.claranet.local> <5880.62.208.225.86.1237974102.squirrel@webmail2.domino.org> <20090325152834.GQ51443@gerbil.cluepon.net> Date: Wed, 25 Mar 2009 15:58:58 -0000 (GMT) From: "Neil J. McRae" To: "Richard A Steenbergen" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil@domino.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:58:20 -0000 On Wed, March 25, 2009 15:28, Richard A Steenbergen wrote: > It seems like your objection is purely theoretical, with no evidence of > any practical problems at all. Please explain to me, in specific terms, > how sending one extra small message which does not propagate or > replicate inside an already established BGP session "does not scale"? Richard, Fair challenge, but in my own view, one of the reasons why BGP works as well as it does is because we haven't infected it with a lot of other stuff not directly related to routing information. Even the example given highlights that its another work around to other bad working practices but we've done the Max Prefix debate to death already. However, with such an way of inserting messages and having experienced many BGP failures owing to different vendor interpretations, I believe this has the potential to introduce more operational risk (limited yes but there nonetheless). I also believe that this is the not right direction for a routing protocol to take. Thin end of the wedge also springs to mind, but this isn't a massive issue for me, just one that I feel I need to air. Regards, Neil. -- Neil J. McRae -- Alive and Kicking. neil@DOMINO.ORG From neil@domino.org Wed Mar 25 09:13:27 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBDCC3A67D1 for ; Wed, 25 Mar 2009 09:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Myf+3ljZnSe8 for ; Wed, 25 Mar 2009 09:13:27 -0700 (PDT) Received: from defiant.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by core3.amsl.com (Postfix) with ESMTP id A8B0F3A6B08 for ; Wed, 25 Mar 2009 09:13:22 -0700 (PDT) Received: from webmail2.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by defiant.domino.org (Postfix) with ESMTP id CDA8BA6C4A; Wed, 25 Mar 2009 16:14:13 +0000 (GMT) Received: from 62.208.225.86 (proxying for 148.185.70.8) (SquirrelMail authenticated user neil) by webmail2.domino.org with HTTP; Wed, 25 Mar 2009 16:14:13 -0000 (GMT) Message-ID: <26622.62.208.225.86.1237997653.squirrel@webmail2.domino.org> In-Reply-To: <49CA5497.7070107@raszuk.net> References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD7F@EXVS01.claranet.local> <5880.62.208.225.86.1237974102.squirrel@webmail2.domino.org> <20090325152834.GQ51443@gerbil.cluepon.net> <49CA5497.7070107@raszuk.net> Date: Wed, 25 Mar 2009 16:14:13 -0000 (GMT) From: "Neil J. McRae" To: robert@raszuk.net User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil@domino.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:13:27 -0000 On Wed, March 25, 2009 15:58, Robert Raszuk wrote: > Talking about size ... is 140 bytes good enough ? "$2/Mb PHONE NOW ON 1-800-TRANSIT" ! The more I think about this the more I think its a bad idea. I like the idea of standard message codes though. -- Neil J. McRae -- Alive and Kicking. neil@DOMINO.ORG From will@harg.net Wed Mar 25 09:19:02 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4E43A6869 for ; Wed, 25 Mar 2009 09:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAI2Sx7s8ccf for ; Wed, 25 Mar 2009 09:19:01 -0700 (PDT) Received: from microserf.flarg.net (microserf.flarg.net [195.177.252.111]) by core3.amsl.com (Postfix) with ESMTP id 83CC03A67D1 for ; Wed, 25 Mar 2009 09:19:01 -0700 (PDT) Received: from bey.net.ic.ac.uk ([155.198.51.110]) by microserf.flarg.net with asmtp (Exim 3.35 #1 (Debian)) id 1LmVpO-0001jR-00; Wed, 25 Mar 2009 16:19:42 +0000 Message-ID: <49CA599D.4020506@harg.net> Date: Wed, 25 Mar 2009 16:19:41 +0000 From: Will Hargrave User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: erosen@cisco.com References: <22319.1237995158@erosen-linux> In-Reply-To: <22319.1237995158@erosen-linux> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:19:02 -0000 Eric Rosen wrote: [snip] > All I can say is that when I was managing a large international mailing > list, I would have jumped for joy at the prospect of eliminating the SMTP > text strings in favor of a set of well-defined error codes ;-) RFC2821 says that the numerical portion is intended for machines and the free form text is intended for humans to aid with troubleshooting. It sounds like your problems resulted more from a lack of available numerical reply code types to describe the problem at hand, rather than a requirement to parse the text portion. But I was not there, so feel free to correct me on this :-) I think a key part of the proposal is the ability to convey messages about a situation we haven't come across yet, so cannot yet standardise or form process for. Will From ras@gerbil.cluepon.net Wed Mar 25 09:26:49 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FDAB3A6928 for ; Wed, 25 Mar 2009 09:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Niz5VUvqXAD8 for ; Wed, 25 Mar 2009 09:26:48 -0700 (PDT) Received: from gerbil.cluepon.net (e-gerbil.net [69.31.1.2]) by core3.amsl.com (Postfix) with ESMTP id 17FEE3A67FD for ; Wed, 25 Mar 2009 09:26:48 -0700 (PDT) Received: from gerbil.cluepon.net (ras@localhost [127.0.0.1]) by gerbil.cluepon.net (8.14.3/8.14.3) with ESMTP id n2PGRbuP093363; Wed, 25 Mar 2009 11:27:37 -0500 (CDT) (envelope-from ras@gerbil.cluepon.net) Received: (from ras@localhost) by gerbil.cluepon.net (8.14.3/8.14.3/Submit) id n2PGRbJH093362; Wed, 25 Mar 2009 11:27:37 -0500 (CDT) (envelope-from ras) Date: Wed, 25 Mar 2009 11:27:37 -0500 From: Richard A Steenbergen To: Eric Rosen Message-ID: <20090325162737.GS51443@gerbil.cluepon.net> References: <22319.1237995158@erosen-linux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22319.1237995158@erosen-linux> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: idr , "Seely, Ted A \[CTO\]" Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:26:49 -0000 On Wed, Mar 25, 2009 at 11:32:38AM -0400, Eric Rosen wrote: > Without taking a position on this draft, I would like to make a comment. > > > I agree that structured messages certainly have their place ... but I > > don't think this replaces the benefits of a free-form text message > > There are protocols that convey errors and/or advisory notices in free-from > text messages. SMTP is one prominent example. > > The result is that for every condition of note, there are dozens of possible > text strings you might get. Further, the identical text string from two > different implementations might mean two completely different things. Not > only that, the text string might be in a language not understood by the > recipient, or even in a language that can't be meaningfully displayed at the > receiving end. You're talking about specific errors with specific causes, which I completely agree should be reported with specific standardized error codes. I don't think it would be appropriate to replace all NOTIFICATION messages with free form text either, for example. SMTP is also not an always connected protocol which is synchronizing state for the routing of potentially many tens of billions of bits/sec on every session, with serious technical and financial consequences if it becomes disconnected for even a few seconds. These are very different protocols with very different goals. The one thing I really don't understand the arguments being made against this draft from a theoretical "protocol purity" perspective. To me this seems to have as much logic as saying "we shouldn't send notification codes because this is a routing protocol and sending messages like this does not help routing, we should send ipsec authenticated syslog to convey the reason for the notification to keep the protocol pure". The argument that "$x is an existing method for doing something therefore we should always use it" also strikes me as incorrect. SMTP is a method for sending communication between devices on the Internet, therefore we should use it implement routing protocols? No, SMTP is a method for delivering e-mail to an extremely large base of users on the Internet, but it is not necessarily the only or best way to communicate between two devices on the Internet. This isn't about using BGP as a chat system, this is about adding a mechanism to better operate and troubleshoot the protocol, using the protocol itself as a pre-configured and pre-authenticated way to convey these messages. In my mind it is little different from a NOTIFICATION message being used to the same effect, and it has the bonus of being remarkably simple to implement. These other proposals look like horrible kludges to accomplish the same goal, but they're so complicated and introduce so many new inter-network communication hassles that I don't see a way anyone would ever implement them. At the end of the day, are we trying to design a "pure" protocol, or are we trying to help network operators make BGP work better for its intended goal as a routing protocol? -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From ras@gerbil.cluepon.net Wed Mar 25 09:30:22 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E73D3A6ABF for ; Wed, 25 Mar 2009 09:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snOS1GlkXfLV for ; Wed, 25 Mar 2009 09:30:21 -0700 (PDT) Received: from gerbil.cluepon.net (e-gerbil.net [69.31.1.2]) by core3.amsl.com (Postfix) with ESMTP id D6DA73A68F6 for ; Wed, 25 Mar 2009 09:30:19 -0700 (PDT) Received: from gerbil.cluepon.net (ras@localhost [127.0.0.1]) by gerbil.cluepon.net (8.14.3/8.14.3) with ESMTP id n2PGV9Zl093393; Wed, 25 Mar 2009 11:31:10 -0500 (CDT) (envelope-from ras@gerbil.cluepon.net) Received: (from ras@localhost) by gerbil.cluepon.net (8.14.3/8.14.3/Submit) id n2PGV97h093392; Wed, 25 Mar 2009 11:31:09 -0500 (CDT) (envelope-from ras) Date: Wed, 25 Mar 2009 11:31:09 -0500 From: Richard A Steenbergen To: "Neil J. McRae" Message-ID: <20090325163109.GT51443@gerbil.cluepon.net> References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD7F@EXVS01.claranet.local> <5880.62.208.225.86.1237974102.squirrel@webmail2.domino.org> <20090325152834.GQ51443@gerbil.cluepon.net> <49CA5497.7070107@raszuk.net> <26622.62.208.225.86.1237997653.squirrel@webmail2.domino.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26622.62.208.225.86.1237997653.squirrel@webmail2.domino.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:30:22 -0000 On Wed, Mar 25, 2009 at 04:14:13PM -0000, Neil J. McRae wrote: > > On Wed, March 25, 2009 15:58, Robert Raszuk wrote: > > > Talking about size ... is 140 bytes good enough ? > > "$2/Mb PHONE NOW ON 1-800-TRANSIT" ! > > The more I think about this the more I think its a bad idea. > I like the idea of standard message codes though. No one has proposed propagating the messages across the Internet, this is purely a point-to-point message between two directly connected neighbors. If you don't like the messages your neighbor sends you, vote with a shutdown. I have yet to see spam end up in a SONET path trace, which is the closest equivalent to the draft being discussed. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From elmi@detebe.org Wed Mar 25 09:47:30 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7717A3A693C for ; Wed, 25 Mar 2009 09:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdKTecM3tzOe for ; Wed, 25 Mar 2009 09:47:29 -0700 (PDT) Received: from ronin.4ever.de (elmi4711-1-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:1108::2]) by core3.amsl.com (Postfix) with ESMTP id 7EDD63A67D1 for ; Wed, 25 Mar 2009 09:47:29 -0700 (PDT) Received: from elmi by ronin.4ever.de with local (Exim 4.50 (FreeBSD)) id 1LmWH6-000IGW-J0; Wed, 25 Mar 2009 17:48:20 +0100 Date: Wed, 25 Mar 2009 17:48:20 +0100 From: "Elmar K. Bins" To: "SCHOLL, TOM (ATTLABS)" Message-ID: <20090325164820.GO74388@ronin.4ever.de> References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> Organization: unorganized since 1789 X-Whisky: Knockando, extra old reserve X-Ncc-RegID: de.denic User-Agent: Mutt/1.5.9i Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:47:30 -0000 Re Tom, ts3127@att.com (SCHOLL, TOM (ATTLABS)) wrote: > > - store the (last) message in the BGP neighbour's info > > - display that message in "show * neighbor xxx" output > > > > _then_ this would be helpful. Otherwise there would be no > > improvement. Basing a protocol upon implementation specifics, > > because it would be useless if implemented in another way...? > > In the slides I presented, initial feedback included a request to have > the equivalent of a "sticky" message. This would transmit to a neighbor > and would be visible via "show bgp nei " output. Honestly, if you think this way then this should be in your proposal. And then, still, I'd object because - this isn't routing info being transmitted (anyone want to introduce the like in OSPF or ISIS?) and thus doesn't belong in BGP transmissions - it doesn't really help (because if my peer's router crashes or one of either ports at the exchange just goes down, I cannot deduce any information from the non-existence of such message) unless I already should have been warned through different - SOP - channels (meaning prearranged and planned outage), thus is just cluttering BGP. > Are you saying that you'd agree with this functionality? It would be the only way for the idea to make sense and thus would need to be in the proposal. Then you base everything on implementation specifics. Can you really not think of a better way to communicate planned outages to your peers? Is this the last straw? Yours, Elmar. From robert@raszuk.net Wed Mar 25 09:59:49 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F1B3A677D for ; Wed, 25 Mar 2009 09:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9JuvHZmFg9t for ; Wed, 25 Mar 2009 09:59:48 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 24BDD3A67FD for ; Wed, 25 Mar 2009 09:59:48 -0700 (PDT) Received: (qmail 27095 invoked by uid 399); 25 Mar 2009 17:00:40 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.240.237) by mail37.opentransfer.com with SMTP; 25 Mar 2009 17:00:40 -0000 Message-ID: <49CA6334.9030100@raszuk.net> Date: Wed, 25 Mar 2009 10:00:36 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Elmar K. Bins" References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> <20090325164820.GO74388@ronin.4ever.de> In-Reply-To: <20090325164820.GO74388@ronin.4ever.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:59:49 -0000 Hi Elmar, > - this isn't routing info being transmitted (anyone want to > introduce the like in OSPF or ISIS?) and thus doesn't belong > in BGP transmissions Actually on this you are not fully right. The amount of non routing information carried in IGPs today is huge :) Look at the mpls traffic eng alone ... Perhaps let me suggest analogy to this solution from the IGP world. In IGP just for reuse of good IGP flooding there is OSPF transport instance defined draft-ietf-ospf-transport-instance They came with this idea too late and have already bunch of non routing stuff carrier in the routing instance. Perhaps let's just do things right in BGP to start with. Why not to define a BGP-CI (communication instance) and use it for exchange of such advisory information without any impact to routing ? From operator's point of view if the need is so strong (in which I don't fully believe) it would be fully transparent. For implementations as well as for mitigation of the impact much safer yet still allowing the very same functionality (or in fact more :) as proposed originally. Comments ? R. From robert@raszuk.net Wed Mar 25 10:38:01 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9353A6D26 for ; Wed, 25 Mar 2009 10:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7dVZ5Hf74dD for ; Wed, 25 Mar 2009 10:38:01 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id C6B593A6BBA for ; Wed, 25 Mar 2009 10:38:00 -0700 (PDT) Received: (qmail 32438 invoked by uid 399); 25 Mar 2009 17:38:53 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.240.237) by mail37.opentransfer.com with SMTP; 25 Mar 2009 17:38:53 -0000 Message-ID: <49CA6C29.6080701@raszuk.net> Date: Wed, 25 Mar 2009 10:38:49 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Marco Rodrigues References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com><20090325164820.GO74388@ronin.4ever.de> <49CA6334.9030100@raszuk.net> <295627243C91274CBCE3C52BBB7E3D86025530A1@emailwf3.jnpr.net> In-Reply-To: <295627243C91274CBCE3C52BBB7E3D86025530A1@emailwf3.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:38:01 -0000 Hi Marco, >> Perhaps let's just do things right in BGP to start with. Why not to >> define a BGP-CI (communication instance) and use it for exchange of >> such advisory information without any impact to routing ? > > Are you suggesting another parallel connection between neighbors > designed specifically to only carry communication information? Wouldn't > one want to consider the scaling issues with this approach? * Those sessions could be on demand and short lived. * The timers responsible for communication protocol can be much less aggressive then for a routing protocol instance. * The amount of information would be (hopefully) much smaller then BGP table for the sigma of SAFIs today, but I don't this this would be a concern as long as we run it separate. * The process responsible for handling this BGP instance can run at much lower CPU priority as compared with the main BGP. Sure both will end up using TCP sessions but all above that can be separated. In fact one could run it on totally different core of the RP CPU or on different RE. * Equally it could be a new instance of BGP as it could be just a TCP SSL connection most of today's implementations support it today already. The point is keep it separate from routing and this point is met if we would go that path :-) Cheers, R. From prvs=3283a79c5=jheitz@redback.com Wed Mar 25 10:40:15 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1FBD28C1D9 for ; Wed, 25 Mar 2009 10:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6Kb-w7jqF3d for ; Wed, 25 Mar 2009 10:40:14 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id E4A253A686E for ; Wed, 25 Mar 2009 10:40:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,420,1233561600"; d="scan'208";a="491399" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 25 Mar 2009 10:41:07 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3FE66C32E09 for ; Wed, 25 Mar 2009 10:41:07 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06941-02 for ; Wed, 25 Mar 2009 10:41:07 -0700 (PDT) Received: from [127.0.0.1] (unknown [155.53.112.59]) by prattle.redback.com (Postfix) with ESMTP id 75B3BA6DFF3 for ; Wed, 25 Mar 2009 10:41:06 -0700 (PDT) Message-ID: <49CA6CB1.8050907@redback.com> Date: Wed, 25 Mar 2009 10:41:05 -0700 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: idr References: <22319.1237995158@erosen-linux> <20090325162737.GS51443@gerbil.cluepon.net> In-Reply-To: <20090325162737.GS51443@gerbil.cluepon.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:46:49 -0000 This is what management protocols were invented for. A management protocol is sepatated from the equipment it's managing, so that it can operate when that equipment is faulty. Also called "out of band". It can be maintained separately from the managed equipment. Eg, load a new MIB. It can be hooked into other automated processes: network management systems. The management protocol for internet equipment is SNMP, not email. Use it. Richard A Steenbergen wrote: > On Wed, Mar 25, 2009 at 11:32:38AM -0400, Eric Rosen wrote: > >> Without taking a position on this draft, I would like to make a comment. >> >> >>> I agree that structured messages certainly have their place ... but I >>> don't think this replaces the benefits of a free-form text message >>> >> There are protocols that convey errors and/or advisory notices in free-from >> text messages. SMTP is one prominent example. >> >> The result is that for every condition of note, there are dozens of possible >> text strings you might get. Further, the identical text string from two >> different implementations might mean two completely different things. Not >> only that, the text string might be in a language not understood by the >> recipient, or even in a language that can't be meaningfully displayed at the >> receiving end. >> > > You're talking about specific errors with specific causes, which I > completely agree should be reported with specific standardized error > codes. I don't think it would be appropriate to replace all NOTIFICATION > messages with free form text either, for example. SMTP is also not an > always connected protocol which is synchronizing state for the routing > of potentially many tens of billions of bits/sec on every session, with > serious technical and financial consequences if it becomes disconnected > for even a few seconds. These are very different protocols with very > different goals. > > The one thing I really don't understand the arguments being made against > this draft from a theoretical "protocol purity" perspective. To me this > seems to have as much logic as saying "we shouldn't send notification > codes because this is a routing protocol and sending messages like this > does not help routing, we should send ipsec authenticated syslog to > convey the reason for the notification to keep the protocol pure". > > The argument that "$x is an existing method for doing something therefore > we should always use it" also strikes me as incorrect. SMTP is a method > for sending communication between devices on the Internet, therefore we > should use it implement routing protocols? No, SMTP is a method for > delivering e-mail to an extremely large base of users on the Internet, > but it is not necessarily the only or best way to communicate between > two devices on the Internet. > > This isn't about using BGP as a chat system, this is about adding a > mechanism to better operate and troubleshoot the protocol, using the > protocol itself as a pre-configured and pre-authenticated way to convey > these messages. In my mind it is little different from a NOTIFICATION > message being used to the same effect, and it has the bonus of being > remarkably simple to implement. These other proposals look like horrible > kludges to accomplish the same goal, but they're so complicated and > introduce so many new inter-network communication hassles that I don't > see a way anyone would ever implement them. At the end of the day, are > we trying to design a "pure" protocol, or are we trying to help network > operators make BGP work better for its intended goal as a routing > protocol? > > From robert@raszuk.net Wed Mar 25 10:55:09 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DB73A6BB8 for ; Wed, 25 Mar 2009 10:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCJj2LU6jFNq for ; Wed, 25 Mar 2009 10:55:08 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 1E8E93A6BBA for ; Wed, 25 Mar 2009 10:55:08 -0700 (PDT) Received: (qmail 16504 invoked by uid 399); 25 Mar 2009 17:56:00 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.240.237) by mail37.opentransfer.com with SMTP; 25 Mar 2009 17:56:00 -0000 Message-ID: <49CA702C.5090808@raszuk.net> Date: Wed, 25 Mar 2009 10:55:56 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jakob Heitz References: <22319.1237995158@erosen-linux> <20090325162737.GS51443@gerbil.cluepon.net> <49CA6CB1.8050907@redback.com> In-Reply-To: <49CA6CB1.8050907@redback.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:55:09 -0000 Hi Jakob, > This is what management protocols were invented for. > A management protocol is sepatated from the equipment it's > managing, so that it can operate when that equipment is faulty. > Also called "out of band". > It can be maintained separately from the managed equipment. Eg, load a > new MIB. > It can be hooked into other automated processes: network management > systems. > The management protocol for internet equipment is SNMP, not email. > Use it. I think SNMP works well intra-domain. This little thread is focusing on inter-domian tools. I have a lot of sympathy for Tom, Richard and others for asking for a tool which would provide them automated easy ability to communicate with peers. Apparently there is not enough of good management tools which would focus on inter-AS communication. All I know I pretty contain to your own AS. We need to keep in mind that today's most routers while quite capable of don't have fully automated way or well documented for that matter to auto generate information and even send it out of band to interested parties. Maintaining a valid list of those interested parties is also a good exercise if we keep this as a manual process. Let's start with that. Phase II would be to worry about how to distribute those information inter-as. I will still argue that they should not mixed with routing, but I see a need for other ways and the pendulum of choices is wide and I think we could satisfy the need without exposing any risk on current BGP4 as a routing protocol. Cheers, R. From jsw@inconcepts.biz Wed Mar 25 11:15:23 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E71C3A67B4 for ; Wed, 25 Mar 2009 11:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.212 X-Spam-Level: * X-Spam-Status: No, score=1.212 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkOUhKQyJc9G for ; Wed, 25 Mar 2009 11:15:22 -0700 (PDT) Received: from odyssey.inconcepts.biz (unknown [69.31.82.162]) by core3.amsl.com (Postfix) with SMTP id 631BC3A696F for ; Wed, 25 Mar 2009 11:15:22 -0700 (PDT) Received: (qmail 7217 invoked from network); 25 Mar 2009 18:16:14 -0000 Received: from 96-28-163-106.dhcp.insightbb.com (HELO ?96.28.163.106?) (96.28.163.106) by colo-69-31-82-163.pilosoft.com with SMTP; 25 Mar 2009 18:16:14 -0000 From: Jeff S Wheeler To: idr@ietf.org In-Reply-To: <49CA6C29.6080701@raszuk.net> References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> <20090325164820.GO74388@ronin.4ever.de> <49CA6334.9030100@raszuk.net> <295627243C91274CBCE3C52BBB7E3D86025530A1@emailwf3.jnpr.net> <49CA6C29.6080701@raszuk.net> Content-Type: text/plain Organization: Innovative Network Concepts LLC Date: Wed, 25 Mar 2009 14:18:25 -0400 Message-Id: <1238005105.2110.35.camel@guardian.inconcepts.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:15:23 -0000 On Wed, 2009-03-25 at 10:38 -0700, Robert Raszuk wrote: > * The process responsible for handling this BGP instance can run at much > lower CPU priority as compared with the main BGP. Sure both will end up > using TCP sessions but all above that can be separated. In fact one > could run it on totally different core of the RP CPU or on different RE. Now you want to add more complexity by running a separate BGP session, suggesting that vendors implement it using a separate process context, and put it on another CPU core? I don't know if Force10 can maintain their aggressive margins if they have to upgrade their platforms from three CPUs to four. Perhaps you should solicit more vendor input. > * Equally it could be a new instance of BGP as it could be just a TCP > SSL connection most of today's implementations support it today already. Are we worried about AMS-IX sniffing the content of the messages and learning about your secret pending maintenance window, even though you are advertising it to your BGP neighbors? Did you intend to put some secret information in the message, like "please change BGP MD5 to 123456 after session goes down?" Or maybe you were going to include your American Express number in case the same person who runs the routers also bills customers? > The point is keep it separate from routing and this point is met if we > would go that path :-) I thought you were concerned about adding complexity to the router software, but your suggestions above seem contrary to that notion. > Phase II would be to worry about how to distribute those information > inter-as. I will still argue that they should not mixed with routing, > but I see a need for other ways and the pendulum of choices is wide and > I think we could satisfy the need without exposing any risk on current > BGP4 as a routing protocol. Having read your six posts on this topic in the past 12 hours, I am totally confused about your position. I won't be surprised if your next post is a BGP5 draft that requires operators to swap one-time-pads for securing the protocol messages and sends SMS notices when the OTP data is nearing exhaustion. But don't add any simple conveniences to the protocol, because if something is going to be useful, it should be hard. In short, my own position on Tom's proposal is that it's a great idea. I think I said something along the lines of, "why didn't someone invent this years ago?" I love the idea that vendors could choose to store a bit of "sticky" information for display in `show bgp neighbor,` even if the session was down. And the very thought of an eBGP neighbor communicating their maintenance advisory to my syslog in haiku brings joy to my heart. My only disappointment is that the proposed buffer sizes and probable lack of newline characters in the eventual standard will not allow for ASCII-art, as roy@Level3.net is a frequent source of joy when searching the IRR databases. Kind regards, -- Jeff S Wheeler +1-212-981-0607 Sr Network Operator / Innovative Network Concepts From robert@raszuk.net Wed Mar 25 11:42:27 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517083A6D8C for ; Wed, 25 Mar 2009 11:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKRSpElZGqg8 for ; Wed, 25 Mar 2009 11:42:26 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 5F7063A6D7A for ; Wed, 25 Mar 2009 11:42:26 -0700 (PDT) Received: (qmail 28626 invoked by uid 399); 25 Mar 2009 18:43:18 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.240.237) by mail37.opentransfer.com with SMTP; 25 Mar 2009 18:43:18 -0000 Message-ID: <49CA7B42.7050301@raszuk.net> Date: Wed, 25 Mar 2009 11:43:14 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jeff S Wheeler References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> <20090325164820.GO74388@ronin.4ever.de> <49CA6334.9030100@raszuk.net> <295627243C91274CBCE3C52BBB7E3D86025530A1@emailwf3.jnpr.net> <49CA6C29.6080701@raszuk.net> <1238005105.2110.35.camel@guardian.inconcepts.net> In-Reply-To: <1238005105.2110.35.camel@guardian.inconcepts.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:42:27 -0000 Jeff, > Now you want to add more complexity by running a separate BGP session, What complexity you are talking about ? It can be as transparent for you CLI wise as enabling the new BGP message the original draft talks about. > suggesting that vendors implement it using a separate process context, > and put it on another CPU core? I don't know if Force10 can maintain > their aggressive margins if they have to upgrade their platforms from > three CPUs to four. Perhaps you should solicit more vendor input. That's an option not a requirement. If you keep routing and informational warnings/automated events together you are loosing that option. > after session goes down?" Or maybe you were going to include your > American Express number in case the same person who runs the routers > also bills customers? No .. I was going to keep your customers from getting free text spam. In the IX case it can be quite likely that some peers want to spoof messages and make their business enemy to wake up at 4:00 am Sunday morning. If you are proposing to have such massages in plane text on the wire, no option for MD5, no option for GTSM, no option for any protection you are welcome. >> The point is keep it separate from routing and this point is met if we >> would go that path :-) > > I thought you were concerned about adding complexity to the router > software, but your suggestions above seem contrary to that notion. Nope. This is not a forum to discuss any implementation complexity in the router. I was and still are concerned about repeating mistakes made in the past of mixing routing and non-routing information in the same protocol just because it is there already and it's distribution nature scales. I am not saying let's forget about the idea all together. All I am saying is that achieving your goal of seeing this extra bit of history info in "sh bgp neighbor" display can be easily accomplished in dozens of ways - many of them with no risk/impact to routing at all. R. From jsw@inconcepts.biz Wed Mar 25 13:37:23 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065CC28C0F3 for ; Wed, 25 Mar 2009 13:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.19 X-Spam-Level: * X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smIgO0mv150Z for ; Wed, 25 Mar 2009 13:37:22 -0700 (PDT) Received: from odyssey.inconcepts.biz (unknown [69.31.82.162]) by core3.amsl.com (Postfix) with SMTP id 055723A6997 for ; Wed, 25 Mar 2009 13:37:21 -0700 (PDT) Received: (qmail 10859 invoked from network); 25 Mar 2009 20:38:13 -0000 Received: from 96-28-163-106.dhcp.insightbb.com (HELO ?96.28.163.106?) (96.28.163.106) by colo-69-31-82-163.pilosoft.com with SMTP; 25 Mar 2009 20:38:13 -0000 From: Jeff S Wheeler To: idr@ietf.org In-Reply-To: <49CA7B42.7050301@raszuk.net> References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> <20090325164820.GO74388@ronin.4ever.de> <49CA6334.9030100@raszuk.net> <295627243C91274CBCE3C52BBB7E3D86025530A1@emailwf3.jnpr.net> <49CA6C29.6080701@raszuk.net> <1238005105.2110.35.camel@guardian.inconcepts.net> <49CA7B42.7050301@raszuk.net> Content-Type: text/plain Organization: Innovative Network Concepts LLC Date: Wed, 25 Mar 2009 16:40:25 -0400 Message-Id: <1238013625.2110.70.camel@guardian.inconcepts.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:37:23 -0000 On Wed, 2009-03-25 at 11:43 -0700, Robert Raszuk wrote: > > suggesting that vendors implement it using a separate process context, > > and put it on another CPU core? I don't know if Force10 can maintain > That's an option not a requirement. If you keep routing and > In the IX case it can be quite likely that some peers want to spoof > messages and make their business enemy to wake up at 4:00 am Sunday > morning. If you are proposing to have such massages in plane text on the > wire, no option for MD5, no option for GTSM, no option for any > protection you are welcome. Did I miss the slide in Tom's presentation that says, "advisory message will be excluded from TCP MD5?" Oh, no, there was no such slide. You just don't know how BGP with MD5 works. I suggest you read RFC2385. > >> The point is keep it separate from routing and this point is met if we > >> would go that path :-) > > > > I thought you were concerned about adding complexity to the router > > software, but your suggestions above seem contrary to that notion. > > Nope. This is not a forum to discuss any implementation complexity in > the router. Really? Because someone suggested separating the advisory messages onto an independent session run in an isolated process context with a low scheduler priority on a CPU core distinct from the one running BGP. That sounds like a lot of implementation complexity to me. Let's use The Google to find out whose idea that was ... results: On Wed, 2009-03-25 at 10:38 -0700, Robert Raszuk wrote: > * The process responsible for handling this BGP instance can run at much > lower CPU priority as compared with the main BGP. Sure both will end up > using TCP sessions but all above that can be separated. In fact one > could run it on totally different core of the RP CPU or on different RE. Oh, I see, it was your doppelganger. > I was and still are concerned about repeating mistakes made in the past > of mixing routing and non-routing information in the same protocol just > because it is there already and it's distribution nature scales. You have already incorrectly identified traffic engineering information as irrelevant to routing. I see nothing intrinsically wrong with extending an existing protocol or signaling mechanism to carry new information. Calling Party Name isn't needed to complete telephone calls, but we have that on top of SS7. ANI isn't even needed, but again, it made sense to include it there. I doubt that Jon Postel envisioned DNS being used as a database of spam sources or open proxies. > I am not saying let's forget about the idea all together. All I am > saying is that achieving your goal of seeing this extra bit of history > info in "sh bgp neighbor" display can be easily accomplished in dozens > of ways - many of them with no risk/impact to routing at all. Now you think it's valuable to have the information displayed via the `show bgp neighbor` output, but think there are better ways than by exchanging the information via the BGP session? Do you suggest the router learn to receive, as well as send, email? What happened to your conviction that generating email to noc@ was a better idea? Kind regards, -- Jeff S Wheeler +1-212-981-0607 Sr Network Operator / Innovative Network Concepts From robert@raszuk.net Wed Mar 25 13:46:57 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893F63A6DBE for ; Wed, 25 Mar 2009 13:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbRwF7kB0iQd for ; Wed, 25 Mar 2009 13:46:56 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id B05E23A6DBB for ; Wed, 25 Mar 2009 13:46:56 -0700 (PDT) Received: (qmail 12822 invoked by uid 399); 25 Mar 2009 20:47:48 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.50.47) by mail37.opentransfer.com with SMTP; 25 Mar 2009 20:47:48 -0000 Message-ID: <49CA9871.70208@raszuk.net> Date: Wed, 25 Mar 2009 13:47:45 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jeff S Wheeler References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> <20090325164820.GO74388@ronin.4ever.de> <49CA6334.9030100@raszuk.net> <295627243C91274CBCE3C52BBB7E3D86025530A1@emailwf3.jnpr.net> <49CA6C29.6080701@raszuk.net> <1238005105.2110.35.camel@guardian.inconcepts.net> <49CA7B42.7050301@raszuk.net> <1238013625.2110.70.camel@guardian.inconcepts.net> In-Reply-To: <1238013625.2110.70.camel@guardian.inconcepts.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 20:46:57 -0000 > Now you think it's valuable to have the information displayed via the > `show bgp neighbor` output, but think there are better ways than by > exchanging the information via the BGP session? Correct. > Do you suggest the router learn to receive, as well as send, email? No. > What happened to your > conviction that generating email to noc@ was a better idea? It is still the same idea. It just requires an open mind to grasp it apparently. Router generates notifications out-of-band of routing information, those end up in syslogs of the peers, routers can display the info just by retrieving it from syslog. Done. Cheers, R. From prvs=3284a844d=nalawade@redback.com Wed Mar 25 14:24:43 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841873A6ACF for ; Wed, 25 Mar 2009 14:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L0AcAZKSU0V for ; Wed, 25 Mar 2009 14:24:42 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id A3CA83A6AD0 for ; Wed, 25 Mar 2009 14:24:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,421,1233561600"; d="scan'208";a="497075" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 25 Mar 2009 14:25:35 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 663C185B88E; Wed, 25 Mar 2009 14:25:35 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20543-05; Wed, 25 Mar 2009 14:25:35 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 45AF485B88C; Wed, 25 Mar 2009 14:25:35 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Wed, 25 Mar 2009 14:25:35 -0700 From: Gargi Nalawade To: Danny McPherson , "SCHOLL, TOM (ATTLABS)" Date: Wed, 25 Mar 2009 14:24:12 -0700 Thread-Topic: [Idr] draft-scholl-idr-advisory-00 Thread-Index: Acms6ZLSRB2mjK2DSyqQi+sH7/Xo3gApnes0 Message-ID: References: <22087C66F061B24EA008D146B7E9164304213778@gaalpa1msgusr73.ITServices.sbc.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:55:32 -0000 Actually that was what the WG had suggested using instead in 2002/3, when t= he draft on the INFORM message was not accepted as a WG item. -Gargi ________________________________________ From: idr-bounces@ietf.org [idr-bounces@ietf.org] On Behalf Of Danny McPher= son [danny@tcb.net] Sent: Tuesday, March 24, 2009 6:21 PM To: SCHOLL, TOM (ATTLABS) Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 On Mar 24, 2009, at 3:08 PM, SCHOLL, TOM (ATTLABS) wrote: > During the session yesterday, Dave Ward brought up that syslog was a > potentially viable option. Tom, I _think he was being facetious... -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr= From prvs=3284a844d=nalawade@redback.com Wed Mar 25 14:29:13 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC36E28C12C for ; Wed, 25 Mar 2009 14:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjEWDT1B7hBg for ; Wed, 25 Mar 2009 14:29:13 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 15D9C3A6A69 for ; Wed, 25 Mar 2009 14:29:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,421,1233561600"; d="scan'208";a="497182" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 25 Mar 2009 14:30:05 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 21EF920D7DB; Wed, 25 Mar 2009 14:30:05 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22146-09; Wed, 25 Mar 2009 14:30:05 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 35ABD34F008; Wed, 25 Mar 2009 14:30:04 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Wed, 25 Mar 2009 14:30:04 -0700 From: Gargi Nalawade To: Yakov Rekhter , "idr@ietf.org" Date: Wed, 25 Mar 2009 14:27:43 -0700 Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcmtUxN7iBHynVBzSMK6FDY35s1z0wAPXSt8 Message-ID: References: <200903251351.n2PDpSM90637@magenta.juniper.net> In-Reply-To: <200903251351.n2PDpSM90637@magenta.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:55:40 -0000 The draft should be updated to specify procedures for upgrading with this e= xtension, before being considered for a WG doc, IMHO. In its current form, it requires a flash upgrade of the network to ensure t= hat there are no routing loops, as Enke also pointed out. -Gargi ________________________________________ From: idr-bounces@ietf.org [idr-bounces@ietf.org] On Behalf Of Yakov Rekhte= r [yakov@juniper.net] Sent: Wednesday, March 25, 2009 6:51 AM To: idr@ietf.org Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Folks, We received a request to accept draft-rosen-idr-aigp-00.txt as an IDR WG document. The deadline for comments on this request is April 8, 2009. If anyone is aware of the IPR related to the draft, please follow the procedurs of rfc3979. Yakov. ------- Forwarded Message Date: Tue, 24 Mar 2009 22:09:29 -0700 From: "Pradosh Mohapatra (pmohapat)" To: "idr" Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document The authors would like to request that draft-rosen-idr-aigp-00.txt be adopted as an IDR WG document. We presented it yesterday @ IDR. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr= From heas@shrubbery.net Wed Mar 25 15:04:03 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A088F28C101 for ; Wed, 25 Mar 2009 15:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Pr+9ayOqe8b for ; Wed, 25 Mar 2009 15:04:02 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by core3.amsl.com (Postfix) with ESMTP id BE8B43A68A7 for ; Wed, 25 Mar 2009 15:04:02 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 7DF70108696; Wed, 25 Mar 2009 22:04:55 +0000 (UTC) Date: Wed, 25 Mar 2009 22:04:55 +0000 From: john heasley To: idr@ietf.org Message-ID: <20090325220455.GI5832@shrubbery.net> References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> <20090325164820.GO74388@ronin.4ever.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090325164820.GO74388@ronin.4ever.de> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:04:03 -0000 Wed, Mar 25, 2009 at 05:48:20PM +0100, Elmar K. Bins: > Re Tom, > > ts3127@att.com (SCHOLL, TOM (ATTLABS)) wrote: > > > > - store the (last) message in the BGP neighbour's info > > > - display that message in "show * neighbor xxx" output > > > > > > _then_ this would be helpful. Otherwise there would be no > > > improvement. Basing a protocol upon implementation specifics, > > > because it would be useless if implemented in another way...? > > > > In the slides I presented, initial feedback included a request to have > > the equivalent of a "sticky" message. This would transmit to a neighbor > > and would be visible via "show bgp nei " output. > > Honestly, if you think this way then this should be in your proposal. > And then, still, I'd object because > > - this isn't routing info being transmitted (anyone want to > introduce the like in OSPF or ISIS?) and thus doesn't belong > in BGP transmissions > > - it doesn't really help (because if my peer's router crashes or one > of either ports at the exchange just goes down, I cannot deduce any > information from the non-existence of such message) unless I already > should have been warned through different - SOP - channels (meaning > prearranged and planned outage), thus is just cluttering BGP. > > > > Are you saying that you'd agree with this functionality? > > It would be the only way for the idea to make sense and thus would need > to be in the proposal. Then you base everything on implementation specifics. > > Can you really not think of a better way to communicate planned outages > to your peers? Is this the last straw? I agree with Elmar and Seely; this proposal seems vastly silly. This is not routing information, it does not belong in the protocol. If a protocol- supported identification of planned maintenance is truely necessary, add a notification(s) more explicit than 'cease'. Such as 'administrative cease/shutdown', 'reboot', and so on. Note that notifications can also carry optional "data", such as a string: router#reload in 1:00 load new ios And, build some redundancy into your MTAs, or whatever your peer-communication channels are, if you're concerned that it may be unavailable when a maint. notification is sent. And, if you have so much trouble with your peers communicating planned maintenance information to you, stop peering with them on the basis of incompetence. From prvs=3284a844d=nalawade@redback.com Wed Mar 25 15:44:36 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA523A6DC6 for ; Wed, 25 Mar 2009 15:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFyP9ci4wWoH for ; Wed, 25 Mar 2009 15:44:35 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 852703A6DC5 for ; Wed, 25 Mar 2009 15:44:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,422,1233561600"; d="scan'208";a="498543" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 25 Mar 2009 15:45:28 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 76AB0286B83; Wed, 25 Mar 2009 15:45:28 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14264-10; Wed, 25 Mar 2009 15:45:28 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id 4F83E286B81; Wed, 25 Mar 2009 15:45:28 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Wed, 25 Mar 2009 15:45:28 -0700 From: Gargi Nalawade To: "erosen@cisco.com" , "Seely, Ted A [CTO]" Date: Wed, 25 Mar 2009 15:45:28 -0700 Thread-Topic: [Idr] draft-scholl-idr-advisory-00 Thread-Index: AcmtXvNf0Cm2Nct2TpaPNOXoVe33VQAO3Yuy Message-ID: References: Your message of Tue, 24 Mar 2009 14:43:22 -0500. , <22319.1237995158@erosen-linux> In-Reply-To: <22319.1237995158@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:44:36 -0000 >> I agree that structured messages certainly have their place ... but= I >> don't think this replaces the benefits of a free-form text message > >There are protocols that convey errors and/or advisory notices in free-fr= om >text messages. SMTP is one prominent example. > >The result is that for every condition of note, there are dozens of possib= le >text strings you might get. Further, the identical text string from t= wo >different implementations might mean two completely different things. N= ot >only that, the text string might be in a language not understood by t= he >recipient, or even in a language that can't be meaningfully displayed at t= he >receiving end. > >There's also the prospect of text strings which do not accurately descri= be >the condition that elicited them. E.g., ever have a browser tell y= ou >"cannot contact host" when the problem is that the local DNS resolver = is >down? Isnt that what standardization is for? So that all implementations could ag= ree on what to send and interpret? =20 In which case we would be talking about standardizing text strings now or abbreviating them and we are back to message codes. -Gargi= From heas@shrubbery.net Wed Mar 25 15:58:31 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06D63A6DB4 for ; Wed, 25 Mar 2009 15:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfiBqIx7OBAj for ; Wed, 25 Mar 2009 15:58:31 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by core3.amsl.com (Postfix) with ESMTP id 20C7F28C1CA for ; Wed, 25 Mar 2009 15:58:31 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id ED790108696; Wed, 25 Mar 2009 22:59:23 +0000 (UTC) Date: Wed, 25 Mar 2009 22:59:23 +0000 From: john heasley To: Yakov Rekhter , idr@ietf.org Message-ID: <20090325225923.GB22584@shrubbery.net> References: <200903251351.n2PDpSM90637@magenta.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:58:31 -0000 Why is AIGP considered before local-preference in best path selection? LP is our trump card. In Cisco's algorithm, it is also before locally originated/redistributed routes. Was the intention that it be before ASPATH? > > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On > > Behalf Of Yakov Rekhter > > Sent: Wednesday, March 25, 2009 9:51 AM > > To: idr@ietf.org > > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document > > > > Folks, > > > > We received a request to accept draft-rosen-idr-aigp-00.txt > > as an IDR WG document. The deadline for comments on this > > request is April 8, 2009. > > > > If anyone is aware of the IPR related to the draft, please > > follow the procedurs of rfc3979. > > > > Yakov. > > ------- Forwarded Message > > > > Date: Tue, 24 Mar 2009 22:09:29 -0700 > > From: "Pradosh Mohapatra (pmohapat)" > > To: "idr" > > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document > > > > The authors would like to request that > > draft-rosen-idr-aigp-00.txt be adopted as an IDR WG document. > > We presented it yesterday @ IDR. From robert@raszuk.net Wed Mar 25 16:08:45 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B9A3A6932 for ; Wed, 25 Mar 2009 16:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xNhFjrS21w1 for ; Wed, 25 Mar 2009 16:08:44 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 9F6B23A680C for ; Wed, 25 Mar 2009 16:08:44 -0700 (PDT) Received: (qmail 886 invoked by uid 399); 25 Mar 2009 23:09:36 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.50.47) by mail37.opentransfer.com with SMTP; 25 Mar 2009 23:09:36 -0000 Message-ID: <49CAB9AC.2020906@raszuk.net> Date: Wed, 25 Mar 2009 16:09:32 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: john heasley References: <200903251351.n2PDpSM90637@magenta.juniper.net> <20090325225923.GB22584@shrubbery.net> In-Reply-To: <20090325225923.GB22584@shrubbery.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:08:45 -0000 Hi John, > Why is AIGP considered before local-preference in best path selection? > LP is our trump card. In Cisco's algorithm, it is also before locally > originated/redistributed routes. Was the intention that it be before > ASPATH? Yes that was exactly the intention when we discussed this at the design phase. But I am yet to get convinced that MED + Cost Community with POI before AS_PATH length is not a better alternative to the problem at hand. Cheers, R. From robert@raszuk.net Wed Mar 25 16:15:55 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C953A6D58 for ; Wed, 25 Mar 2009 16:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4QYTcxgAq7W for ; Wed, 25 Mar 2009 16:15:55 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 56EF13A6DBC for ; Wed, 25 Mar 2009 16:14:53 -0700 (PDT) Received: (qmail 5386 invoked by uid 399); 25 Mar 2009 23:15:45 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.50.47) by mail37.opentransfer.com with SMTP; 25 Mar 2009 23:15:45 -0000 Message-ID: <49CABB1D.2010500@raszuk.net> Date: Wed, 25 Mar 2009 16:15:41 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gargi Nalawade References: <200903251351.n2PDpSM90637@magenta.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org" Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:15:55 -0000 Hi Gargi, > The draft should be updated to specify procedures for upgrading with > this extension, before being considered for a WG doc, IMHO. > > In its current form, it requires a flash upgrade of the network to > ensure that there are no routing loops, as Enke also pointed out. I don't think it requires flash upgrade as defined today. Note that this is to be contained by design to a single service provider which may consist of more then one AS. The feature is off by default and enabled when all _essential_ network elements are upgraded with the new functionality. Just to note - If you are running some form of encapsulation (for example MPLS) within your ASes such number of nodes to upgrade to make this useful is significantly reduced. Cheers, R. From david.freedman@uk.clara.net Wed Mar 25 16:31:20 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E7028C171 for ; Wed, 25 Mar 2009 16:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f-lXPcWvvgP for ; Wed, 25 Mar 2009 16:31:19 -0700 (PDT) Received: from staff01.mail.eu.clara.net (unknown [IPv6:2001:a88:0:fff7::54]) by core3.amsl.com (Postfix) with ESMTP id CF89528C1D8 for ; Wed, 25 Mar 2009 16:31:18 -0700 (PDT) Received: from [192.168.201.201] (port=59027 helo=srvukfe01.claranet.local) by staff01.mail.eu.clara.net (staff01.mail.eu.clara.net [80.168.65.54]:25) with esmtp id 1LmcZt-0007Ld-66 (Exim 4.69) for idr@ietf.org (return-path ); Wed, 25 Mar 2009 23:32:10 +0000 Received: from EXVS01.claranet.local ([192.168.201.205]) by srvukfe01.claranet.local with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 23:34:15 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ADA2.361E5FF2" Date: Wed, 25 Mar 2009 23:34:16 -0000 Message-ID: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD9E@EXVS01.claranet.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-scholl-idr-advisory-00 thread-index: AcmtojYeIfAHWdGuQBiaY4G+O2E/Ww== From: "David Freedman" To: X-OriginalArrivalTime: 25 Mar 2009 23:34:15.0908 (UTC) FILETIME=[36008240:01C9ADA2] X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:31:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ADA2.361E5FF2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >If a protocol-=20 >supported identification of planned maintenance is truely necessary Can we please stop limiting the scope of this to simply conveying = planned maintenance announcements,=20 I want a non-terminal NOTIFICATION to be carried INSIDE BGP, that is my = main care here.=20 Give me a nonterminal NOTIFICATION and I'll be happy. Dave. ------------------------------------------------ David Freedman Group Network Engineering=20 Claranet Limited http://www.clara.net ------_=_NextPart_001_01C9ADA2.361E5FF2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: draft-scholl-idr-advisory-00

>If a protocol-
>supported identification of planned maintenance is truely = necessary

Can we please stop limiting the scope of this to simply conveying = planned maintenance announcements,
I want a non-terminal NOTIFICATION to be carried INSIDE BGP, that is my = main care here.
Give me a nonterminal NOTIFICATION and I'll be happy.

Dave.


------------------------------------------------
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net

------_=_NextPart_001_01C9ADA2.361E5FF2-- From elmi@detebe.org Wed Mar 25 17:53:53 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625E83A6A13 for ; Wed, 25 Mar 2009 17:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBLvqV0ilWwE for ; Wed, 25 Mar 2009 17:53:52 -0700 (PDT) Received: from ronin.4ever.de (elmi4711-1-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:1108::2]) by core3.amsl.com (Postfix) with ESMTP id 704DE3A6832 for ; Wed, 25 Mar 2009 17:53:52 -0700 (PDT) Received: from elmi by ronin.4ever.de with local (Exim 4.50 (FreeBSD)) id 1Lmdrn-000K39-UV for idr@ietf.org; Thu, 26 Mar 2009 01:54:43 +0100 Date: Thu, 26 Mar 2009 01:54:43 +0100 From: "Elmar K. Bins" To: idr@ietf.org Message-ID: <20090326005443.GP74388@ronin.4ever.de> References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> <20090325164820.GO74388@ronin.4ever.de> <49CA6334.9030100@raszuk.net> <295627243C91274CBCE3C52BBB7E3D86025530A1@emailwf3.jnpr.net> <49CA6C29.6080701@raszuk.net> <1238005105.2110.35.camel@guardian.inconcepts.net> <49CA7B42.7050301@raszuk.net> <1238013625.2110.70.camel@guardian.inconcepts.net> <49CA9871.70208@raszuk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49CA9871.70208@raszuk.net> Organization: unorganized since 1789 X-Whisky: Knockando, extra old reserve X-Ncc-RegID: de.denic User-Agent: Mutt/1.5.9i Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:53:53 -0000 (Yeah, go out for a couple rounds of badminton and people start real heat...) I have a couple of annotations and one or two questions... robert@raszuk.net (Robert Raszuk) wrote: > It is still the same idea. It just requires an open mind to grasp it > apparently. Router generates notifications out-of-band of routing > information, those end up in syslogs of the peers, routers can display > the info just by retrieving it from syslog. I would actually prefer the info in the "noc view" of the network. My router might be unreachable if things get really hairy. And this "noc view" need not pull that info from some BGP stream on some remote router. I agree (maybe that wasn't so clear in previous emails) with the general idea of having a -- ideally standardised -- solution for passing operational info to my peers and other parties with a valid interest (exchanges, customers, transits, the press...) Yet, transporting this kind of info is not the job of the routing protocol itself. I am convinced that this should happen out-of-band wrt/BGP. This would give the benefit of being able to communicate an incident even if this doesn't work over that peering anymore ;-) So, yes, Jeff, we'd all be happy had someone invented this years ago, but would we really want it inside the routing protocol? What about communicating available downstream bandwidth to the n-th degree inside named protocol? What about maintainance windows of customers? Discussions about birthday presents? I agree, something like Tom envisioned is definitely needed. It should be drafted and then implemented, and that needs to be done outside IDR, in a group that's more operations-focused, but at the same time not limited to the BGP peering view. In that way, not only this one special problem can be solved, but a lot more could be achieved. Btw, I also agree with you, Jeff, that a little bit of fun can easen the pain of a big peer going down for maintainance. I'd love the Haiku bit. Just not in the router ;-) To David I have a probably silly question: david.freedman@uk.clara.net (David Freedman) wrote: > >If a protocol- > >supported identification of planned maintenance is truely necessary > > Can we please stop limiting the scope of this to simply conveying planned maintenance announcement > I want a non-terminal NOTIFICATION to be carried INSIDE BGP, that is my main care here. > Give me a nonterminal NOTIFICATION and I'll be happy. Maybe my grasp of english is not sufficient here, or I just don't get the term, but what do you mean by "non-terminal notification"? Yours (and good night), Elmar. From pmohapat@cisco.com Wed Mar 25 18:01:29 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35AA28C18C for ; Wed, 25 Mar 2009 18:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzDbr2SmtAR0 for ; Wed, 25 Mar 2009 18:01:29 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E3E3628C17B for ; Wed, 25 Mar 2009 18:01:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,422,1233532800"; d="scan'208";a="32351401" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 26 Mar 2009 01:02:21 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2Q12LxP001802; Wed, 25 Mar 2009 18:02:21 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2Q12L2l007958; Thu, 26 Mar 2009 01:02:21 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 18:02:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 18:02:20 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408F2EFA3@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcmtUxN7iBHynVBzSMK6FDY35s1z0wAPXSt8AAdj/eA= References: <200903251351.n2PDpSM90637@magenta.juniper.net> From: "Pradosh Mohapatra (pmohapat)" To: "Gargi Nalawade" , "Yakov Rekhter" , X-OriginalArrivalTime: 26 Mar 2009 01:02:21.0687 (UTC) FILETIME=[84926070:01C9ADAE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=876; t=1238029341; x=1238893341; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[Idr]=20draft-rosen-idr-aigp-00.txt=20a s=20IDR=20WG=20document |Sender:=20; bh=YVDANJuiiOgh0/4GwKVZunz0yDBpZxQ8RAnAyDj0gso=; b=famxgbA7aOIL9xn8oF/GENReY8n7PDE0LHv4VoP8WVw4pT5TfOy88k2Q1z CvIBmUTDXf6az8SWS+AfsX0qKDyhmaagXVmnW4WE+b4FfZcigR0UrArQGqPP qBPsaWOGyg; Authentication-Results: sj-dkim-4; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:01:29 -0000 Hi Gargi, | The draft should be updated to specify procedures for=20 | upgrading with this extension, before being considered for a=20 | WG doc, IMHO. |=20 | In its current form, it requires a flash upgrade of the=20 | network to ensure that there are no routing loops, as Enke=20 | also pointed out. No, it doesn't. Section 3.1 of the document talks about the applicability: This document only considers the use of the AIGP attribute in networks where each router uses tunneling of some sort to deliver a packet to its BGP next hop. Use of the AIGP attribute in networks that do not use tunneling is outside the scope of this document. There is no flash upgrade required with this in mind. If a router is not upgraded, the bestpath selection will not be what is desired (so could be sub-optimal)... and that's=20 about it. - Pradosh From samitac@ipinfusion.com Wed Mar 25 18:49:00 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372013A680A for ; Wed, 25 Mar 2009 18:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPghNvYNrvlJ for ; Wed, 25 Mar 2009 18:48:59 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 481423A6967 for ; Wed, 25 Mar 2009 18:48:59 -0700 (PDT) Received: (qmail 10036 invoked from network); 26 Mar 2009 01:49:52 -0000 Received: from unknown (HELO samitacD630) (samitac@130.129.16.141 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 26 Mar 2009 01:49:51 -0000 X-YMail-OSG: _tKOJvkVM1kMxhlZ_Vs39WqPt0N.gCJvEZAfs2oC88e53mZu6aaFS7PhYuiuccn14DgLCBy1jUxoroMcsMOXVOLYI.fjAs7zaQ3Xwilf6jWfgTlXS8kNJns7IJTixgRyYz..4ziSA0PSDk6If4P_A.Xq X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Pradosh Mohapatra \(pmohapat\)'" Date: Wed, 25 Mar 2009 18:49:51 -0700 Message-ID: <064a01c9adb5$27ac0300$77040900$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_064B_01C9AD7A.7B4D2B00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmttSLAElXZfpeJQhGbMpS1r9xLqw== Content-Language: en-us x-cr-hashedpuzzle: EwRt F216 GYTq I973 MZj3 MhRA Oz/C P4pF P/Hq Qi4o S0Lu TX54 VL0Z Veg3 Vnrt XJwk; 2; aQBkAHIAQABpAGUAdABmAC4AbwByAGcAOwBwAG0AbwBoAGEAcABhAHQAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sosha1_v1; 7; {DB371BBC-FDD1-4111-992F-093BD17CEB06}; cwBhAG0AaQB0AGEAYwBAAGkAcABpAG4AZgB1AHMAaQBvAG4ALgBjAG8AbQA=; Thu, 26 Mar 2009 01:49:44 GMT; ZAByAGEAZgB0AC0AcgBmAGUAcgBuAGEAbgBkAG8ALQBpAGQAcgAtAGwAaQBuAGsALQBiAGEAbgBkAHcAaQBkAHQAaAAtADAAMAAgAC0AIABhAG4AIABpAGQAZQBhAA== x-cr-puzzleid: {DB371BBC-FDD1-4111-992F-093BD17CEB06} Cc: idr@ietf.org Subject: [Idr] draft-rfernando-idr-link-bandwidth-00 - an idea X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:49:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_064B_01C9AD7A.7B4D2B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pradosh, This is just an idea that might be applicable to your draft on link-bandwidth extended community. I think this draft is useful. Since we discussed at the meeting that the 2-byte AS number is not really useful [ same AS in IBGP] and it can only carry AS_TRANS for 4byte AS case, I wonder if that field can be used for carrying link characteristics related information ? If we do not have ideas right now what other link characteristics might be useful, this field can be made as RESERVED ( all zeroes) for future use. Comments? Thanks, -Samita ------=_NextPart_000_064B_01C9AD7A.7B4D2B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pradosh,

 

This is just an idea that might be applicable to = your draft on link-bandwidth extended community.

I think this draft is useful. Since we discussed at = the meeting that the 2-byte AS number is not really useful [ same AS in = IBGP] and it can only carry AS_TRANS for 4byte AS case, I wonder if that field can = be used for carrying link characteristics related information ?  If we = do not have ideas right now what other link characteristics might be useful, = this field can be made as RESERVED ( all zeroes) for future = use.

Comments?

 

Thanks,

-Samita

------=_NextPart_000_064B_01C9AD7A.7B4D2B00-- From david.freedman@uk.clara.net Wed Mar 25 18:53:13 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230CE3A6A10 for ; Wed, 25 Mar 2009 18:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjy-HFJRESv8 for ; Wed, 25 Mar 2009 18:53:12 -0700 (PDT) Received: from staff01.mail.eu.clara.net (unknown [IPv6:2001:a88:0:fff7::54]) by core3.amsl.com (Postfix) with ESMTP id E01943A680F for ; Wed, 25 Mar 2009 18:52:52 -0700 (PDT) Received: from [192.168.201.202] (port=35338 helo=srvukfe02.claranet.local) by staff01.mail.eu.clara.net (staff01.mail.eu.clara.net [80.168.65.54]:25) with esmtp id 1Lmemo-00036V-5w (Exim 4.69) for idr@ietf.org (return-path ); Thu, 26 Mar 2009 01:53:44 +0000 Received: from EXVS01.claranet.local ([192.168.201.205]) by srvukfe02.claranet.local with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 01:55:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ADB5.EDB78EB6" Date: Thu, 26 Mar 2009 01:55:24 -0000 Message-ID: <1BD38DD97E9BEB40A599BFCCED93CC7F04CDA4@EXVS01.claranet.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-scholl-idr-advisory-00 thread-index: Acmtte2yhhKKoyo2RDGoEcsUs4xaPw== From: "David Freedman" To: X-OriginalArrivalTime: 26 Mar 2009 01:55:24.0508 (UTC) FILETIME=[EDAE51C0:01C9ADB5] X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:53:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ADB5.EDB78EB6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Maybe my grasp of english is not sufficient here, or I just don't get = the=20 >term, but what do you mean by "non-terminal notification"? Sorry, it's quite late here, but to clarify, RFC4271=20 sec 3 states: "NOTIFICATION messages are sent in response to errors or special conditions. If a connection encounters an error condition, a NOTIFICATION message is sent and the connection is closed. " sec 4.5 states: "4.5. NOTIFICATION Message Format A NOTIFICATION message is sent when an error condition is detected. The BGP connection is closed immediately after it is sent. " So basically, when a NOTIFICATION message is sent, the session must be = closed,=20 this is what I mean by "terminal". I don't think it is right in all circumstances to terminate the session = if the "condition" is recoverable / nonfatal. I think the ADVISORY message and its predecessor the INFORM both satisfy = this,=20 a way of informing you a "condition of interest" occured but that it was = not=20 an error, nor fatal to me (nor to you) and we should continue the = session. It should be optional to receive, negotiated by capability , the = capability should indicate that you can either send, receive or do both. If you = have not negotiated the capability, or negotiated the capability indicating that you will = only send (and not receive) then nobody should be sending to you, to do so would be an error on = their part and you should reject=20 such messages. Since the messages are "in-band" with the session, they would be = protected by the same mechanisms (MD5/GTSM) that the session is protected with.=20 The ability for the message to carry plain text (and not a plethora of = attribute types/values)=20 (but limited in size) allows us to be as flexible and as creative with = the use as possible,=20 the inter-noc communication is just one small application for this = (potentially) enabling feature. I understand the reluctance for add something which appears "non = routing" to the protocol, but we already have these messages since they = are related to the transport (and hence the routing path), the = NOTIFICATION already exists (and has to), it was just a shame that we = had to make it terminal in all cases. Dave. ------------------------------------------------ David Freedman Group Network Engineering=20 Claranet Limited http://www.clara.net ------_=_NextPart_001_01C9ADB5.EDB78EB6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: draft-scholl-idr-advisory-00

>Maybe my grasp of english is not sufficient here, = or I just don't get the
>term, but what do you mean by "non-terminal = notification"?

Sorry, it's quite late here, but to clarify, RFC4271

sec 3 states:

"NOTIFICATION messages are sent in response to
   errors or special conditions.  If a connection = encounters an error
   condition, a NOTIFICATION message is sent and the = connection is
   closed.
"

sec 4.5 states:

"4.5.  NOTIFICATION Message Format

   A NOTIFICATION message is sent when an error condition is = detected.
   The BGP connection is closed immediately after it is = sent.
"

So basically, when a NOTIFICATION message is sent, the session must be = closed,
this is what I mean by "terminal".

I don't think it is right in all circumstances to terminate the session = if the "condition"
is recoverable / nonfatal.

I think the ADVISORY message and its predecessor the INFORM both satisfy = this,
a way of informing you a "condition of interest" occured but = that it was not
an error, nor fatal to me (nor to you) and we should continue the = session.

It should be optional to receive, negotiated by capability , the = capability
should indicate that you can either send, receive or do both. If you = have not negotiated
the capability, or negotiated the capability indicating that you will = only send (and not receive)
then nobody should be sending to you, to do so would be an error on = their part and you should reject
such messages.

Since the messages are "in-band" with the session, they would = be protected by the same
mechanisms (MD5/GTSM) that the session is protected with.

The ability for the message to carry plain text (and not a plethora of = attribute types/values)
(but limited in size) allows us to be as flexible and as creative with = the use as possible,
the inter-noc communication is just one small application for this = (potentially) enabling feature.

I understand the reluctance for add something which appears "non = routing" to the protocol, but we already have these messages since = they are related to the transport (and hence the routing path), the = NOTIFICATION already exists (and has to), it was just a shame that we = had to make it terminal in all cases.

Dave.




------------------------------------------------
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net

------_=_NextPart_001_01C9ADB5.EDB78EB6-- From samitac@ipinfusion.com Wed Mar 25 19:26:12 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FBDB28C22B for ; Wed, 25 Mar 2009 19:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=1.467, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3VZ5cLqt0WO for ; Wed, 25 Mar 2009 19:26:07 -0700 (PDT) Received: from n11a.bullet.mail.mud.yahoo.com (n11a.bullet.mail.mud.yahoo.com [209.191.125.176]) by core3.amsl.com (Postfix) with SMTP id F2A8728C265 for ; Wed, 25 Mar 2009 19:26:06 -0700 (PDT) Received: from [68.142.200.226] by n11.bullet.mail.mud.yahoo.com with NNFMP; 26 Mar 2009 02:27:00 -0000 Received: from [68.142.201.246] by t7.bullet.mud.yahoo.com with NNFMP; 26 Mar 2009 02:26:59 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 26 Mar 2009 02:26:59 -0000 X-Yahoo-Newman-Id: 781128.35817.bm@omp407.mail.mud.yahoo.com Received: (qmail 86741 invoked from network); 26 Mar 2009 02:26:59 -0000 Received: from unknown (HELO samitacD630) (samitac@130.129.16.141 with login) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 26 Mar 2009 02:26:58 -0000 X-YMail-OSG: TqGkB2wVM1lbu3vROVr5tmUVfYiTvqs42WW8YRV_zDNAO0mZd_1fLbtAnHB6HkuR_wp5liKa6z95p5fjvVKuvK2TeTpizJ98yDWYlJ0DHoXSmK2G79v39dqOPhgBxwMbdf9W_9YoBfLjOgQRbBKOXPAjhNTvtIWlvnQ_7RewVRAFI98GSe2vliIE X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: Date: Wed, 25 Mar 2009 19:26:58 -0700 Message-ID: <065b01c9adba$56d5bc20$04813460$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_065C_01C9AD7F.AA76E420" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmtulZjlkfqEMXbRbekghFsuwBDCw== Content-Language: en-us Cc: idr@ietf.org Subject: [Idr] Clarification points for rfc4893-bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 02:26:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_065C_01C9AD7F.AA76E420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Enke, This is a follow-up from the idr meeting comments. I'd like to thank you for your kind consideration in taking into some of the comments addressed in draft-chakrabarti-idr-rfc4893-mod. Here are few cases that I propose to clarify in the next revision of the rfc4893-bis and I think these will be helpful for new readers and implementers especially considering the fact that 2byte ASes and 4byte ASes are going to co-exist for sometime. Clarification 1: Section 3: "My AS Number" field Currently it says: " and "We denote this special AS number as AS_TRANS for ease of description in the rest of this specification. This AS number is also placed in the "My Autonomous System" field of the OPEN message originated by a NEW BGP speaker, if the speaker does not have a (globally unique) 2-octet AS number." The clarification would be useful : 1) When 4-byte AS number capability message is present and the receiver is able to process the capability message, should it ignore the AS number field in the OPEN message and use the AS-number present in the capability message? Clarification 2: Minor nit: "truly 4-octet" should be defined as a quantity higher than 65535. Should the NEW BGP speaker send a NOTIFICATION message when it receives a OPEN message with AS_TRANS but without any corresponding capability message ? Note that although AS_TRANS(23456) is a reserved number now, it is still possible to receive a OPEN message with AS_TRANS value from an OLD BGP speaker or from a ill-behaving NEW BGP speaker. Proposal for a NOTIFICATION message When two BGP speakers correspond with each other by sending AS_TRANS value in the 'My AS number' field, then the OPEN message MUST contain the 4-octet AS number capability option. If the 4-octet capability is missing in OPEN message where the 'My AS Number' field contains AS_TRANS value, a NEW BGP speaker-receiver SHOULD send a notification with code=2, subcode=2 [bad peer AS] to the sender of the OPEN message. Clarification on section 6 (Transition) How about some more text on PE-CE cases? Especially the AS_OVERRIDE issue as identified in http://www.ietf.org/proceedings/08mar/slides/idr-4/idr-4.htm [ Please check-out slide 11] Thanks, -Samita ------=_NextPart_000_065C_01C9AD7F.AA76E420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Enke,

 

This is a follow-up from the idr meeting comments. = I’d like to thank you for your kind consideration in taking into some of the comments addressed in draft-chakrabarti-idr-rfc4893-mod.

 

Here are few cases that I propose to clarify in the = next revision of the rfc4893-bis and I think these will be helpful for new = readers and implementers especially considering the fact that 2byte ASes and = 4byte ASes are going to co-exist for sometime.

 

Clarification 1:

Section 3: “My AS Number” = field

Currently it says:

"  and "We denote this special AS number as AS_TRANS for ease = of

   description in the rest of this specification.  This AS number = is

   also placed in the "My Autonomous System" field of the OPEN = message

   originated by a NEW BGP speaker, if the speaker does not have = a

   (globally unique) 2-octet AS number."

 

   The clarification would be useful : 1) When 4-byte AS =
number capability message is
   present =
and the receiver is able to process the capability =
message,
   should it ignore the AS =
number field in the OPEN message and use the AS-number present in the =
capability =
message?
 
 
Clarification 2:
Minor nit: =
"truly 4-octet" should be defined as a quantity =
higher
   than =
65535.
 
   =
Should the NEW BGP speaker send a NOTIFICATION message when =
it
   receives a OPEN message with =
AS_TRANS but without any corresponding
   =
capability message ?  Note that although AS_TRANS(23456) is =
a
   reserved number now, it is still =
possible to receive a OPEN message
   =
with AS_TRANS value from an OLD BGP speaker or from a =
ill-behaving
   NEW BGP =
speaker.
 
Proposal for a =
NOTIFICATION =
message
 
   =
When two BGP speakers correspond with each other by sending =
AS_TRANS
   value in the 'My AS number' =
field, then the OPEN message MUST =
contain
   the 4-octet AS number =
capability option.  If the 4-octet =
capability
   is missing in OPEN message =
where the 'My AS Number' field =
contains
   AS_TRANS value, a NEW BGP =
speaker-receiver SHOULD send a =
notification
   with code=3D2, =
subcode=3D2 [bad peer AS] to the sender of the =
OPEN
   =
message.
 
 

Clarification on section 6 = (Transition)

How about some more text on PE-CE cases? Especially = the AS_OVERRIDE issue as identified in

htt= p://www.ietf.org/proceedings/08mar/slides/idr-4/idr-4.htm [ Please check-out slide 11]

 

 

Thanks,

-Samita

------=_NextPart_000_065C_01C9AD7F.AA76E420-- From dongjie_dj@huawei.com Wed Mar 25 23:13:53 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331A83A6B12 for ; Wed, 25 Mar 2009 23:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.34 X-Spam-Level: X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuQK9SKJCbK2 for ; Wed, 25 Mar 2009 23:13:49 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B16DC3A6923 for ; Wed, 25 Mar 2009 23:13:48 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KH3008GUO0FUS@szxga01-in.huawei.com> for idr@ietf.org; Thu, 26 Mar 2009 14:14:40 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KH3007O4O0FYL@szxga01-in.huawei.com> for idr@ietf.org; Thu, 26 Mar 2009 14:14:39 +0800 (CST) Received: from d65110 ([10.111.12.97]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KH30041FO0EUX@szxml04-in.huawei.com> for idr@ietf.org; Thu, 26 Mar 2009 14:14:39 +0800 (CST) Date: Thu, 26 Mar 2009 14:14:38 +0800 From: Dong Jie In-reply-to: <1BD38DD97E9BEB40A599BFCCED93CC7F04CDA4@EXVS01.claranet.local> To: 'David Freedman' , idr@ietf.org Message-id: <008201c9adda$24f1ec40$610c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_X+OvOMPMqBlBaIERc02Khg)" Thread-index: Acmtte2yhhKKoyo2RDGoEcsUs4xaPwADNhTQ Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 06:13:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_X+OvOMPMqBlBaIERc02Khg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I agree that sending non-terminal information is necessary, but I still have a question: does the ADVISORY message affect routing? If the answer is Yes, then the message should be sent in-band and be parsed by the peering router immediately, so the peering router can make some reaction accordingly. Under this circumstance, the message should not be in free-form, since it needs to be understood by a router. If the answer is No, the message is just some information about "condition of interest", and is for operators (not for routers) to read it sometime later, I think it's not quite necessary to send it in-band, and we can use free-form text message here. IMO, Maybe we could divide the messages into two types: "affect routing" or "not affect routing", and treat them in different ways. Best regards, Dong Jie _____ From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of David Freedman Sent: Thursday, March 26, 2009 9:55 AM To: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 So basically, when a NOTIFICATION message is sent, the session must be closed, this is what I mean by "terminal". I don't think it is right in all circumstances to terminate the session if the "condition" is recoverable / nonfatal. I think the ADVISORY message and its predecessor the INFORM both satisfy this, a way of informing you a "condition of interest" occured but that it was not an error, nor fatal to me (nor to you) and we should continue the session. It should be optional to receive, negotiated by capability , the capability should indicate that you can either send, receive or do both. If you have not negotiated the capability, or negotiated the capability indicating that you will only send (and not receive) then nobody should be sending to you, to do so would be an error on their part and you should reject such messages. Since the messages are "in-band" with the session, they would be protected by the same mechanisms (MD5/GTSM) that the session is protected with. The ability for the message to carry plain text (and not a plethora of attribute types/values) (but limited in size) allows us to be as flexible and as creative with the use as possible, the inter-noc communication is just one small application for this (potentially) enabling feature. I understand the reluctance for add something which appears "non routing" to the protocol, but we already have these messages since they are related to the transport (and hence the routing path), the NOTIFICATION already exists (and has to), it was just a shame that we had to make it terminal in all cases. Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net --Boundary_(ID_X+OvOMPMqBlBaIERc02Khg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable Re: draft-scholl-idr-advisory-00

Hi,

 

I agree that sending non-terminal information = is necessary, but I still have a question: does the ADVISORY message affect = routing?

 

If the answer is Yes, then the message should = be sent in-band and be parsed by the peering router immediately, so the peering = router can make some reaction accordingly.

Under this circumstance, the message should not = be in free-form, since it needs to be understood by a = router.

 

If the answer is No, the message is just some information about "condition of interest", and is for = operators (not for routers) to read it sometime later, I think it’s not quite = necessary to send it in-band, and we can use free-form text message = here.

 

IMO, Maybe we could divide the messages into = two types: “affect routing” or “not affect routing”, and = treat them in different ways.

 

 

Best = regards,

Dong = Jie

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of David Freedman
Sent: Thursday, March 26, = 2009 9:55 AM
To: idr@ietf.org
Subject: Re: [Idr] draft-scholl-idr-advisory-00


So basically, when a NOTIFICATION message is sent, the session must be = closed,
this is what I mean by "terminal".

I don't think it is right in all circumstances to terminate the session = if the "condition"
is recoverable / nonfatal.

I think the ADVISORY message and its predecessor the INFORM both satisfy = this,
a way of informing you a "condition of interest" occured but = that it was not
an error, nor fatal to me (nor to you) and we should continue the = session.

It should be optional to receive, negotiated by capability , the = capability
should indicate that you can either send, receive or do both. If you = have not negotiated
the capability, or negotiated the capability indicating that you will = only send (and not receive)
then nobody should be sending to you, to do so would be an error on = their part and you should reject
such messages.

Since the messages are "in-band" with the session, they would = be protected by the same
mechanisms (MD5/GTSM) that the session is protected with.

The ability for the message to carry plain text (and not a plethora of attribute types/values)
(but limited in size) allows us to be as flexible and as creative with = the use as possible,
the inter-noc communication is just one small application for this (potentially) enabling feature.

I understand the reluctance for add something which appears "non routing" to the protocol, but we already have these messages since = they are related to the transport (and hence the routing path), the = NOTIFICATION already exists (and has to), it was just a shame that we had to make it terminal in all cases.

Dave.




------------------------------------------------
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net

--Boundary_(ID_X+OvOMPMqBlBaIERc02Khg)-- From neil@domino.org Thu Mar 26 01:43:11 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB733A6833 for ; Thu, 26 Mar 2009 01:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUjM6XXWueoR for ; Thu, 26 Mar 2009 01:43:10 -0700 (PDT) Received: from defiant.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by core3.amsl.com (Postfix) with ESMTP id 9FA2A3A6452 for ; Thu, 26 Mar 2009 01:43:10 -0700 (PDT) Received: from webmail2.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by defiant.domino.org (Postfix) with ESMTP id 40560A6EB8; Thu, 26 Mar 2009 08:44:02 +0000 (GMT) Received: from 62.208.225.86 (proxying for 148.185.70.24) (SquirrelMail authenticated user neil) by webmail2.domino.org with HTTP; Thu, 26 Mar 2009 08:44:02 -0000 (GMT) Message-ID: <63546.62.208.225.86.1238057042.squirrel@webmail2.domino.org> In-Reply-To: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD9E@EXVS01.claranet.local> References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD9E@EXVS01.claranet.local> Date: Thu, 26 Mar 2009 08:44:02 -0000 (GMT) From: "Neil J. McRae" To: "David Freedman" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil@domino.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 08:43:11 -0000 On Wed, March 25, 2009 23:34, David Freedman wrote: > Can we please stop limiting the scope of this to simply conveying planned > maintenance announcements, > I want a non-terminal NOTIFICATION to be carried INSIDE BGP, that is my > main care here. > Give me a nonterminal NOTIFICATION and I'll be happy. On this point I agree with Dave its something that is long overdue. Neil. -- Neil J. McRae -- Alive and Kicking. neil@DOMINO.ORG From jsw@inconcepts.biz Thu Mar 26 02:18:12 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE533A682F for ; Thu, 26 Mar 2009 02:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.179 X-Spam-Level: * X-Spam-Status: No, score=1.179 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf9AVlW5eQht for ; Thu, 26 Mar 2009 02:18:11 -0700 (PDT) Received: from odyssey.inconcepts.biz (unknown [69.31.82.162]) by core3.amsl.com (Postfix) with SMTP id 92AE93A6A51 for ; Thu, 26 Mar 2009 02:17:56 -0700 (PDT) Received: (qmail 31939 invoked from network); 26 Mar 2009 09:18:49 -0000 Received: from 96-28-163-106.dhcp.insightbb.com (HELO ?96.28.163.106?) (96.28.163.106) by colo-69-31-82-163.pilosoft.com with SMTP; 26 Mar 2009 09:18:49 -0000 From: Jeff S Wheeler To: idr@ietf.org In-Reply-To: <63546.62.208.225.86.1238057042.squirrel@webmail2.domino.org> References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD9E@EXVS01.claranet.local> <63546.62.208.225.86.1238057042.squirrel@webmail2.domino.org> Content-Type: text/plain Organization: Innovative Network Concepts LLC Date: Thu, 26 Mar 2009 05:21:05 -0400 Message-Id: <1238059265.2110.112.camel@guardian.inconcepts.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 09:18:12 -0000 On Thu, 2009-03-26 at 08:44 +0000, Neil J. McRae wrote: > On Wed, March 25, 2009 23:34, David Freedman wrote: > > Give me a nonterminal NOTIFICATION and I'll be happy. > > On this point I agree with Dave its something that is long overdue. This is not really the intent of the Scholl Plan, but if you are going to imagine up some more convenience features, I would like the remote BGP speaker to occasionally inform me of the number of BGP prefixes I advertise which were rejected by policy, e.g. prefix-list has not been updated. I don't propose that the router send back an acknowledgment each time it chooses to accept a route, but an update at similar interval to keep-alive messages would be a nice capability. To put it in context, how many times have you thought, hrm, I expected more traffic from this neighbor, only to learn that they were rejecting half of your advertisements due to misconfiguration or wrong information supplied to the neighbor? On Wed, 2009-03-25 at 13:47 -0700, Robert Raszuk wrote: > It is still the same idea. It just requires an open mind to grasp it > apparently. Router generates notifications out-of-band of routing > information, those end up in syslogs of the peers, routers can display > the info just by retrieving it from syslog. Well, I guess I'm suggesting another thing that can already be done out-of-band by writing email to the neighbor's NOC or using a web-based route server or well-connected router looking-glass. Consider the time savings and improvement in information availability, though. I'm pretty sure routing protocols were invented to automate the distribution of routing information, reducing work and improving reliability. On Thu, 2009-03-26 at 01:54 +0100, Elmar K. Bins wrote: > I agree, something like Tom envisioned is definitely needed. It should be > drafted and then implemented, and that needs to be done outside IDR, in a > group that's more operations-focused, but at the same time not limited to I agree with you that the IETF is entirely too focused on process and not enough on accomplishing things. -- Jeff S Wheeler +1-212-981-0607 Sr Network Operator / Innovative Network Concepts From rajiva@cisco.com Thu Mar 26 05:07:07 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9CE3A6861 for ; Thu, 26 Mar 2009 05:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sIKGDUz5P1Y for ; Thu, 26 Mar 2009 05:07:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1AFE83A6801 for ; Thu, 26 Mar 2009 05:07:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,426,1233532800"; d="scan'208";a="274503220" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Mar 2009 12:07:59 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n2QC7xXx008813; Thu, 26 Mar 2009 05:07:59 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2QC7xQQ006283; Thu, 26 Mar 2009 12:07:59 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 08:07:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 08:07:57 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6076DE5F8@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <1238059265.2110.112.camel@guardian.inconcepts.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-scholl-idr-advisory-00 Thread-Index: Acmt8+3sffiNjv6fTtC2teHJfkbbCAAF4Eww References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD9E@EXVS01.claranet.local><63546.62.208.225.86.1238057042.squirrel@webmail2.domino.org> <1238059265.2110.112.camel@guardian.inconcepts.net> From: "Rajiv Asati (rajiva)" To: "Jeff S Wheeler" , X-OriginalArrivalTime: 26 Mar 2009 12:07:59.0178 (UTC) FILETIME=[812BE2A0:01C9AE0B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2855; t=1238069279; x=1238933279; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20(rajiva)=22=20 |Subject:=20RE=3A=20[Idr]=20draft-scholl-idr-advisory-00 |Sender:=20; bh=atVxQv250NMjlaFsy8cYG8diTxuVhhjI2vaNeN3DU3U=; b=FKtV4JZ91Scgzpxfb2lgKRfkOQkAbDN1fz9u5ks4cIykA0OQB2HkxL0VDy 7qDnOFz9jM6VhBGqO5cpvGSoU6eIwDBCSGVKez9tVJVEGXRauVMm+Kqn61+2 Dhx5mRKVQk; Authentication-Results: sj-dkim-4; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 12:07:07 -0000 Sounds like the need for soft-notify is back - http://tools.ietf.org/html/draft-nalawade-bgp-soft-notify-01 Cheers, Rajiv > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Jeff S Wheeler > Sent: Thursday, March 26, 2009 5:21 AM > To: idr@ietf.org > Subject: Re: [Idr] draft-scholl-idr-advisory-00 >=20 > On Thu, 2009-03-26 at 08:44 +0000, Neil J. McRae wrote: > > On Wed, March 25, 2009 23:34, David Freedman wrote: > > > Give me a nonterminal NOTIFICATION and I'll be happy. > > > > On this point I agree with Dave its something that is long overdue. > This is not really the intent of the Scholl Plan, but if you are going > to imagine up some more convenience features, I would like the remote > BGP speaker to occasionally inform me of the number of BGP prefixes I > advertise which were rejected by policy, e.g. prefix-list has not been > updated. I don't propose that the router send back an acknowledgment > each time it chooses to accept a route, but an update at similar > interval to keep-alive messages would be a nice capability. >=20 > To put it in context, how many times have you thought, hrm, I expected > more traffic from this neighbor, only to learn that they were rejecting > half of your advertisements due to misconfiguration or wrong > information > supplied to the neighbor? >=20 > On Wed, 2009-03-25 at 13:47 -0700, Robert Raszuk wrote: > > It is still the same idea. It just requires an open mind to grasp it > > apparently. Router generates notifications out-of-band of routing > > information, those end up in syslogs of the peers, routers can > display > > the info just by retrieving it from syslog. > Well, I guess I'm suggesting another thing that can already be done > out-of-band by writing email to the neighbor's NOC or using a web-based > route server or well-connected router looking-glass. Consider the time > savings and improvement in information availability, though. I'm > pretty > sure routing protocols were invented to automate the distribution of > routing information, reducing work and improving reliability. >=20 > On Thu, 2009-03-26 at 01:54 +0100, Elmar K. Bins wrote: > > I agree, something like Tom envisioned is definitely needed. It > should be > > drafted and then implemented, and that needs to be done outside IDR, > in a > > group that's more operations-focused, but at the same time not > limited to > I agree with you that the IETF is entirely too focused on process and > not enough on accomplishing things. >=20 > -- > Jeff S Wheeler +1-212-981-0607 > Sr Network Operator / Innovative Network Concepts >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ras@gerbil.cluepon.net Thu Mar 26 07:58:18 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08843A6A7E for ; Thu, 26 Mar 2009 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7dPUkW31bvb for ; Thu, 26 Mar 2009 07:58:11 -0700 (PDT) Received: from gerbil.cluepon.net (e-gerbil.net [69.31.1.2]) by core3.amsl.com (Postfix) with ESMTP id BBB943A6B4F for ; Thu, 26 Mar 2009 07:57:47 -0700 (PDT) Received: from gerbil.cluepon.net (ras@localhost [127.0.0.1]) by gerbil.cluepon.net (8.14.3/8.14.3) with ESMTP id n2QEwcrg000501; Thu, 26 Mar 2009 09:58:38 -0500 (CDT) (envelope-from ras@gerbil.cluepon.net) Received: (from ras@localhost) by gerbil.cluepon.net (8.14.3/8.14.3/Submit) id n2QEwbBR000500; Thu, 26 Mar 2009 09:58:37 -0500 (CDT) (envelope-from ras) Date: Thu, 26 Mar 2009 09:58:37 -0500 From: Richard A Steenbergen To: "Neil J. McRae" Message-ID: <20090326145837.GA51443@gerbil.cluepon.net> References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD9E@EXVS01.claranet.local> <63546.62.208.225.86.1238057042.squirrel@webmail2.domino.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63546.62.208.225.86.1238057042.squirrel@webmail2.domino.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 14:58:19 -0000 On Thu, Mar 26, 2009 at 08:44:02AM -0000, Neil J. McRae wrote: > > On Wed, March 25, 2009 23:34, David Freedman wrote: > > > Can we please stop limiting the scope of this to simply conveying planned > > maintenance announcements, > > I want a non-terminal NOTIFICATION to be carried INSIDE BGP, that is my > > main care here. > > Give me a nonterminal NOTIFICATION and I'll be happy. > > On this point I agree with Dave its something that is long overdue. In reality, the goals of the advisory msg draft and a soft NOTIFICATION message are almost precisely the same. I suspect the reason the advisory message was drafted this way was to say "here is something extremely trivial to implement, that provides some solution to the problem, free form is better than no message at all even in the cases where it isn't perfect, and we can do it now". I absolutely agree that structured messages for things like max-prefix warnings and other automated router-generated events are the way to go if possible, but I absolutely disagree that implementing a complex out of band message delivery system is the right way to solve what is essentially a need to deliver simple messages in-band. Maybe the right way to approach this is to add soft notifications, define a slew of message types that make sense for all the normal conditions that can be thought of, and just add a message type for free-form text as well. The only feature in the advisory message draft that this wouldn't cover is the "sticky note" concept. It seems like the goal here is to provide a mechanism similar to a SONET path trace but for the BGP session, where you would set a static message in your router config rather than via a CLI operational command, and it would be transmitted and made available in a "show bgp" rather than syslogged as an event requiring immediate action. Some ideas for usage of this include NOC contact information, "circuit id" type information, descriptions of the session (particularly useful in the case of multiple sessions between networks, some configured differently from others), etc. I still like this idea, but I for one would be willing to live without it if it got the support of the protocol purists for implementing the soft notifications above. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From david.freedman@uk.clara.net Thu Mar 26 08:05:37 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7257C3A6DF1 for ; Thu, 26 Mar 2009 08:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRIXv8OZJvL9 for ; Thu, 26 Mar 2009 08:05:36 -0700 (PDT) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id A996D3A6828 for ; Thu, 26 Mar 2009 08:05:36 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.69) (envelope-from ) id 1LmrA4-0005t2-6z for idr@ietf.org; Thu, 26 Mar 2009 15:06:28 +0000 Message-ID: <49CB99F3.5090300@uk.clara.net> Date: Thu, 26 Mar 2009 15:06:27 +0000 From: David Freedman Organization: Claranet LImited User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: idr References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CD9E@EXVS01.claranet.local> <63546.62.208.225.86.1238057042.squirrel@webmail2.domino.org> <20090326145837.GA51443@gerbil.cluepon.net> In-Reply-To: <20090326145837.GA51443@gerbil.cluepon.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 15:05:37 -0000 I still like this idea, but I > for one would be willing to live without it if it got the support of the > protocol purists for implementing the soft notifications above. > +1, I'm happy with SOFT-NOTIFICATION although it is a shame to miss out on some of the features of ADVISORY We could perhaps resurrect SOFT-NOTIFICATION and have the ADVISORY "Sticky" messages be a vendor implementation using SOFT-NOTIFICATION messages Dave. From prvs=32962f32d=nalawade@redback.com Thu Mar 26 10:27:35 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58263A6A7F for ; Thu, 26 Mar 2009 10:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEQIpIcLR--D for ; Thu, 26 Mar 2009 10:27:35 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 007863A690D for ; Thu, 26 Mar 2009 10:27:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,426,1233561600"; d="scan'208";a="515094" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 26 Mar 2009 10:28:28 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C813A452491; Thu, 26 Mar 2009 10:28:28 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20801-08; Thu, 26 Mar 2009 10:28:28 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id B1B8B452490; Thu, 26 Mar 2009 10:28:28 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Thu, 26 Mar 2009 10:28:28 -0700 From: Gargi Nalawade To: "Pradosh Mohapatra (pmohapat)" , Yakov Rekhter , "idr@ietf.org" Date: Thu, 26 Mar 2009 10:28:28 -0700 Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcmtUxN7iBHynVBzSMK6FDY35s1z0wAPXSt8AAdj/eAAIkx4uw== Message-ID: References: <200903251351.n2PDpSM90637@magenta.juniper.net> , <04CAD96D4C5A3D48B1919248A8FE0D5408F2EFA3@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5408F2EFA3@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:35:31 -0000 Hi Pradosh, As per the quoted text, the draft is requiring of all routers in the networ= k to=20 understand the AIGP attribute, right? Which means upgrading the whole=20 network to understand this.=20 If all routers in the network are not upgraded, then some routers would=20 recognize AIGP and do bestpath taking it into account, while others which=20 do not, will run bestpath without it and each could point to different best= paths. Translating - potential routing loops (not just sub-optimal routing). i.e. = Without=20 upgrading the whole network. Thanks, Gargi ________________________________________ From: Pradosh Mohapatra (pmohapat) [pmohapat@cisco.com] Sent: Wednesday, March 25, 2009 6:02 PM To: Gargi Nalawade; Yakov Rekhter; idr@ietf.org Subject: RE: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Hi Gargi, | The draft should be updated to specify procedures for | upgrading with this extension, before being considered for a | WG doc, IMHO. | | In its current form, it requires a flash upgrade of the | network to ensure that there are no routing loops, as Enke | also pointed out. No, it doesn't. Section 3.1 of the document talks about the applicability: This document only considers the use of the AIGP attribute in networks where each router uses tunneling of some sort to deliver a packet to its BGP next hop. Use of the AIGP attribute in networks that do not use tunneling is outside the scope of this document. There is no flash upgrade required with this in mind. If a router is not upgraded, the bestpath selection will not be what is desired (so could be sub-optimal)... and that's about it. - Pradosh= From pmohapat@cisco.com Thu Mar 26 13:55:28 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A513A6876 for ; Thu, 26 Mar 2009 13:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMtQmcs8gW4r for ; Thu, 26 Mar 2009 13:55:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 515103A6867 for ; Thu, 26 Mar 2009 13:55:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,428,1233532800"; d="scan'208";a="147221516" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Mar 2009 20:56:20 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2QKuK2r027552; Thu, 26 Mar 2009 13:56:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2QKuKd1002394; Thu, 26 Mar 2009 20:56:20 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 13:56:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 13:56:19 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408F2F3EF@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcmtUxN7iBHynVBzSMK6FDY35s1z0wAPXSt8AAdj/eAAIkx4uwAHKJWA References: <200903251351.n2PDpSM90637@magenta.juniper.net> , <04CAD96D4C5A3D48B1919248A8FE0D5408F2EFA3@xmb-sjc-215.amer.cisco.com> From: "Pradosh Mohapatra (pmohapat)" To: "Gargi Nalawade" , "Yakov Rekhter" , X-OriginalArrivalTime: 26 Mar 2009 20:56:20.0485 (UTC) FILETIME=[509F7350:01C9AE55] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1939; t=1238100980; x=1238964980; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[Idr]=20draft-rosen-idr-aigp-00.txt=20a s=20IDR=20WG=20document |Sender:=20; bh=6kk1zx/lUEnTRkRX6L65HDivdbeobwvUgGl3YXFSUHQ=; b=0VOkybT+avw/AfeweRBldkAb51Tz7/sNfF2Qro4prHuAyidZ3kh8FXMYw3 q8d3vIl7eOD4xeOpp+duG3u9C47VA5/S+0NQzSENrRmrpGlRdzWukidZdrcA 696jINypcX; Authentication-Results: sj-dkim-2; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 20:55:28 -0000 | As per the quoted text, the draft is requiring of all routers=20 | in the network to understand the AIGP attribute, right? Which=20 | means upgrading the whole network to understand this.=20 |=20 | If all routers in the network are not upgraded, then some=20 | routers would recognize AIGP and do bestpath taking it into=20 | account, while others which do not, will run bestpath without=20 | it and each could point to different bestpaths. | Translating - potential routing loops (not just sub-optimal=20 | routing). i.e. Without upgrading the whole network. If the network deploys tunneling (e.g. label forwarding), we will not get into loops (with partly upgraded routers). - Pradosh |=20 | Thanks, | Gargi |=20 | ________________________________________ | From: Pradosh Mohapatra (pmohapat) [pmohapat@cisco.com] | Sent: Wednesday, March 25, 2009 6:02 PM | To: Gargi Nalawade; Yakov Rekhter; idr@ietf.org | Subject: RE: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document |=20 | Hi Gargi, |=20 | | The draft should be updated to specify procedures for=20 | upgrading with=20 | | this extension, before being considered for a WG doc, IMHO. | | | | In its current form, it requires a flash upgrade of the network to=20 | | ensure that there are no routing loops, as Enke also pointed out. |=20 | No, it doesn't. Section 3.1 of the document talks about the | applicability: |=20 | This document only considers the use of the AIGP attribute in | networks where each router uses tunneling of some sort to deliver a | packet to its BGP next hop. Use of the AIGP attribute in networks | that do not use tunneling is outside the scope of this document. |=20 | There is no flash upgrade required with this in mind. If a=20 | router is not upgraded, the bestpath selection will not be=20 | what is desired (so could be sub-optimal)... and that's about it. |=20 | - Pradosh |=20 From yakov@juniper.net Thu Mar 26 16:24:33 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADFA3A676A for ; Thu, 26 Mar 2009 16:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h-NcMNkbOa4 for ; Thu, 26 Mar 2009 16:24:32 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 8BC4D3A67CC for ; Thu, 26 Mar 2009 16:24:32 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKScwO5kFvA2DQESxhiXmIbhZWRxI97pMB@postini.com; Thu, 26 Mar 2009 16:25:26 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 26 Mar 2009 16:24:55 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 16:24:54 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 16:24:54 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 16:24:53 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2QNOrM14956 for ; Thu, 26 Mar 2009 16:24:53 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903262324.n2QNOrM14956@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4296.1238109893.1@juniper.net> Date: Thu, 26 Mar 2009 16:24:53 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 26 Mar 2009 23:24:53.0951 (UTC) FILETIME=[11766CF0:01C9AE6A] Subject: [Idr] IDR WG LC on BGP MIB X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 23:24:33 -0000 Folks, This is to start IDR WG Last Call on draft-ietf-idr-bgp4-mibv2-09, and draft-ietf-idr-bgp4-mibv2-tc-mib-00. The deadline for comments is April 9, 2009. Yakov. From root@core3.amsl.com Fri Mar 27 10:30:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6D1B23A69C3; Fri, 27 Mar 2009 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090327173001.6D1B23A69C3@core3.amsl.com> Date: Fri, 27 Mar 2009 10:30:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-flow-spec-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 17:30:01 -0000 --NextPart 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 : Dissemination of flow specification rules Author(s) : P. Roque Marques, et al. Filename : draft-ietf-idr-flow-spec-06.txt Pages : 22 Date : 2009-03-27 This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more-specific components of the traffic aggregate defined by an IP destination prefix. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-flow-spec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-27102625.I-D@ietf.org> --NextPart-- From rex@juniper.net Fri Mar 27 12:56:45 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD643A6B65 for ; Fri, 27 Mar 2009 12:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PP90dGjTwKtf for ; Fri, 27 Mar 2009 12:56:44 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 86AA23A687C for ; Fri, 27 Mar 2009 12:56:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSc0vq3onD2qcKBrYWw9PMaSuLKyJgMVu@postini.com; Fri, 27 Mar 2009 12:57:39 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Fri, 27 Mar 2009 12:57:28 -0700 From: Rex Fernando To: 'PAPADIMITRIOU Dimitri' , Yakov Rekhter , "idr@ietf.org" Date: Fri, 27 Mar 2009 12:57:28 -0700 Thread-Topic: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WG document Thread-Index: AcmsiWe7S/jJkEhqTGSkB1MLz3BMbAAGjIagAJq4b7A= Message-ID: In-Reply-To: <00275A5B436CA441900CB10936742A3801F45603@FRVELSMBS22.ad2.ad.alcatel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 19:56:45 -0000 Hi Dimitri, | The Link Bandwidth Community used to be part of the BGP Extended | Communities Attribute document (now RFC4360) until it was removed in v09 | after review. At that it was stated that in order to perform | BW-proportional BGP load-balancing, BGP multipath load balancing should | be first documented. Isn't this condition still valid in the present | case and the corr.mechanisms to be documented beyond limited deployment | consideration part of Section 3? The draft lists the cases (although not in so many words) where link bandwi= dth can be safely deployed i.e. when the candidate paths are identical unti= l the IGP distance step in path selection or you have a tunneled network. E= ither of these would ensure loop freedom. And that's all there is to it. We'll be happy to omit the word "multipath" from the draft since it lacks p= rior definition and expand on the deployment scenarios a bit if you feel st= rongly about it. - Rex From uttaro@att.com Fri Mar 27 19:43:48 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41AEC3A6954 for ; Fri, 27 Mar 2009 19:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.097 X-Spam-Level: X-Spam-Status: No, score=-106.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6WyTT8kb8-x for ; Fri, 27 Mar 2009 19:43:47 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 405573A67D8 for ; Fri, 27 Mar 2009 19:43:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: uttaro@att.com X-Msg-Ref: server-14.tower-146.messagelabs.com!1238208281!5871024!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 16046 invoked from network); 28 Mar 2009 02:44:41 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 28 Mar 2009 02:44:41 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2S2ifBP029984; Fri, 27 Mar 2009 22:44:41 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2S2icJ5029974; Fri, 27 Mar 2009 22:44:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Mar 2009 22:44:38 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7A43F53@misout7msgusr7e.ugd.att.com> In-Reply-To: <20090325225923.GB22584@shrubbery.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcmtnVvOu6fTQgkIRO23z6ADuHLqNwBsJIcw References: <200903251351.n2PDpSM90637@magenta.juniper.net> <20090325225923.GB22584@shrubbery.net> From: "UTTARO, JAMES, ATTLABS" To: "john heasley" , "Yakov Rekhter" , Cc: "NGUYEN, HAN Q, ATTLABS" , "SAAD, SAMIR S, ATTLABS" Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 02:43:48 -0000 The notion is that we are trying to perform a best path selection that is consistent across Multiple AS/IGP domains.. If two or more AS domains and some subset of speakers "agree" to use the AIGP metric then there is an implicit agreement that they will all honor each others IGP Cost methodology and accumulate a metric that is consistent. If we placed AIGP below LP or AS-PATH etc... it would imply tha an AS can a local decision regardless of the information from upstream AS domains ( AIGP metric ). I just want to be clear that AIGP is for a set of AS domains that are all under a common ISP or administrative authority.. AIGP is not appropriate between AS domains under different administrative control.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of john heasley Sent: Wednesday, March 25, 2009 6:59 PM To: Yakov Rekhter; idr@ietf.org Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Why is AIGP considered before local-preference in best path selection? LP is our trump card. In Cisco's algorithm, it is also before locally originated/redistributed routes. Was the intention that it be before ASPATH? > > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 > > Behalf Of Yakov Rekhter > > Sent: Wednesday, March 25, 2009 9:51 AM > > To: idr@ietf.org > > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document > >=20 > > Folks, > >=20 > > We received a request to accept draft-rosen-idr-aigp-00.txt=20 > > as an IDR WG document. The deadline for comments on this=20 > > request is April 8, 2009. > >=20 > > If anyone is aware of the IPR related to the draft, please=20 > > follow the procedurs of rfc3979. > >=20 > > Yakov. > > ------- Forwarded Message > >=20 > > Date: Tue, 24 Mar 2009 22:09:29 -0700 > > From: "Pradosh Mohapatra (pmohapat)" > > To: "idr" > > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document > >=20 > > The authors would like to request that=20 > > draft-rosen-idr-aigp-00.txt be adopted as an IDR WG document.=20 > > We presented it yesterday @ IDR. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From uttaro@att.com Sat Mar 28 09:53:38 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59763A6928 for ; Sat, 28 Mar 2009 09:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.222 X-Spam-Level: X-Spam-Status: No, score=-106.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyzGrixiqtNH for ; Sat, 28 Mar 2009 09:53:38 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id E5A953A67EA for ; Sat, 28 Mar 2009 09:53:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: uttaro@att.com X-Msg-Ref: server-6.tower-167.messagelabs.com!1238259272!8524409!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 27236 invoked from network); 28 Mar 2009 16:54:32 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-167.messagelabs.com with AES256-SHA encrypted SMTP; 28 Mar 2009 16:54:32 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2SGsWI0032600; Sat, 28 Mar 2009 12:54:32 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2SGsSEE032576; Sat, 28 Mar 2009 12:54:28 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 28 Mar 2009 12:54:28 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7A43F54@misout7msgusr7e.ugd.att.com> In-Reply-To: <49C906E6.9030904@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00 Thread-Index: Acmsm6jBdM8RerTbTPm6H0iHS3Wb5gDKUyIg References: <49C906E6.9030904@raszuk.net> From: "UTTARO, JAMES, ATTLABS" To: , "idr" Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 16:53:38 -0000 I do not agree. MED is a tool that is used to signal preference between two AS domains... The idea of overloading for this purpose would require knobs and hacks like "always-compare MED" and accumulating MED etc.... Cost Community would also have to be modified. It is better to create an attribute whose functionality is clear. Use MED and Cost Community for the problems the were designed to solve. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Tuesday, March 24, 2009 12:15 PM To: idr Subject: [Idr] draft-rosen-idr-aigp-00 All, I would like to support the suggestion made yesterday by Enke Chen,=20 Keyur Patel and Danny which suggested to make a good analysis for using=20 MED + Cost Community which are an already existing tools to achieve the=20 same functionality as the draft proposed via a definition of a new AIGP=20 attribute. In fact the problem described in the draft is a very good example where=20 practical problem can be solved using the above two solutions combined=20 together. It can be a very good motivation for restarting work on cost community=20 itself which were last posted draft-retana-bgp-custom-decision-00. There are apparently practical cases which this draft has a potential to solve and IMHO there is a saving to implement something once and then reuse=20 for various applications as opposed to implementing separate attributes=20 which would at the end result in more burden to BGP and deployment=20 difficulties. Cheers, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From Dimitri.Papadimitriou@alcatel-lucent.be Sat Mar 28 10:07:43 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB393A6A85 for ; Sat, 28 Mar 2009 10:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMQ8NxzBtORI for ; Sat, 28 Mar 2009 10:07:42 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id CD8493A6A03 for ; Sat, 28 Mar 2009 10:07:39 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2SH8NNx020331; Sat, 28 Mar 2009 18:08:23 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 28 Mar 2009 18:08:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Mar 2009 18:08:22 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801F86AFB@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument Thread-Index: AcmsiWe7S/jJkEhqTGSkB1MLz3BMbAAGjIagAJq4b7AALO+fUA== References: <00275A5B436CA441900CB10936742A3801F45603@FRVELSMBS22.ad2.ad.alcatel.com> From: "PAPADIMITRIOU Dimitri" To: "Rex Fernando" , "Yakov Rekhter" , X-OriginalArrivalTime: 28 Mar 2009 17:08:23.0486 (UTC) FILETIME=[CD5285E0:01C9AFC7] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 17:07:43 -0000 Hi Fernando:=20 > -----Original Message----- > From: Rex Fernando [mailto:rex@juniper.net]=20 > Sent: Friday, March 27, 2009 8:57 PM > To: PAPADIMITRIOU Dimitri; Yakov Rekhter; idr@ietf.org > Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt=20 > as IDR WGdocument >=20 > Hi Dimitri, >=20 > | The Link Bandwidth Community used to be part of the BGP Extended > | Communities Attribute document (now RFC4360) until it was=20 > removed in v09 > | after review. At that it was stated that in order to perform > | BW-proportional BGP load-balancing, BGP multipath load=20 > balancing should > | be first documented. Isn't this condition still valid in=20 > the present > | case and the corr.mechanisms to be documented beyond=20 > limited deployment > | consideration part of Section 3? >=20 > The draft lists the cases (although not in so many words)=20 > where link bandwidth can be safely deployed i.e. when the=20 > candidate paths are identical until the IGP distance step in=20 > path selection or you have a tunneled network. Either of=20 > these would ensure loop freedom. And that's all there is to it. >=20 > We'll be happy to omit the word "multipath" from the draft=20 > since it lacks prior definition and expand on the deployment=20 > scenarios a bit if you feel strongly about it. I think we have first to agree on the definition of "link bandwidth" - either consider the link bandwidth as the "nominal link capacity" which is thus a fixed and configured value (equivalent to link cost) that does not result in variability in the multipath selection process at the border router (PE1 in the slide material) beside local policy decision. this would lead to a control-driven usage of this attribute. - or consider the link bandwidth as the "available link bandwidth" aka "residual capacity" which thus leaves possibility for varying the multipath selection process over time depending on the actual value of this attribute. this would lead to a traffic-driven usage of this attribute.=20 I would be advisable that you clarify on this point to see how to consider Section 3 statement: "The usage of this community is restricted to the cases where BGP multipath can be safely deployed." Thanks, -dimitri. > - Rex >=20 >=20 From robert@raszuk.net Sat Mar 28 17:46:44 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8C83A68AB for ; Sat, 28 Mar 2009 17:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upsW7KV6YWrB for ; Sat, 28 Mar 2009 17:46:43 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 1081C3A6863 for ; Sat, 28 Mar 2009 17:46:43 -0700 (PDT) Received: (qmail 16960 invoked by uid 399); 29 Mar 2009 00:47:38 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.45.72) by mail37.opentransfer.com with SMTP; 29 Mar 2009 00:47:38 -0000 Message-ID: <49CEC525.9040306@raszuk.net> Date: Sat, 28 Mar 2009 17:47:33 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "UTTARO, JAMES, ATTLABS" References: <49C906E6.9030904@raszuk.net> <1477DEAE19DD884CB004730D0FD77FD7A43F54@misout7msgusr7e.ugd.att.com> In-Reply-To: <1477DEAE19DD884CB004730D0FD77FD7A43F54@misout7msgusr7e.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 00:46:44 -0000 Hi Jim, I think there are few things which would be great to keep in mind no matter how this proposal will move forward. * I think that making new attribute is clean indeed, but a bit risky to touch your best path selection algorithm each time new attribute is invented to influence best path decision. * As defined today AIGP attribute carries an unreferenced sigma of metrics. In my opinion it should be referenced by the start point of the accumulation which most obviously would be the originator next hop. Best path should compare only those AIGP attributes with original next hop attached to be equal. Otherwise in deployments in other customer networks when AIGP support is partial in the mesh of ASes it is quite obvious that it may lead to permanent loops. Any encapsulation (even mpls) on a per AS basis will not be a cure at all. * And to the point you made ... cost community where designed to be common tool to modify the best path selection on as needed basis. Do you have a different opinion on cost community applicability ? Their design is exactly as you require in your case. Yes it would need to accumulate MEDs metrics on the AS boundaries, but this is the same as adding new values to the new to be deployed AIGP attribute. Best regards, R. > I do not agree. MED is a tool that is used to signal preference between > two AS domains... The idea of overloading for this purpose would require > knobs and hacks like "always-compare MED" and accumulating MED etc.... > Cost Community would also have to be modified. It is better to create an > attribute whose functionality is clear. Use MED and Cost Community for > the problems the were designed to solve. > > Jim Uttaro > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Robert Raszuk > Sent: Tuesday, March 24, 2009 12:15 PM > To: idr > Subject: [Idr] draft-rosen-idr-aigp-00 > > All, > > I would like to support the suggestion made yesterday by Enke Chen, > Keyur Patel and Danny which suggested to make a good analysis for using > MED + Cost Community which are an already existing tools to achieve the > same functionality as the draft proposed via a definition of a new AIGP > attribute. > > In fact the problem described in the draft is a very good example where > practical problem can be solved using the above two solutions combined > together. > > It can be a very good motivation for restarting work on cost community > itself which were last posted draft-retana-bgp-custom-decision-00. There > > are apparently practical cases which this draft has a potential to solve > > and IMHO there is a saving to implement something once and then reuse > for various applications as opposed to implementing separate attributes > which would at the end result in more burden to BGP and deployment > difficulties. > > Cheers, > R. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From danny@tcb.net Sun Mar 29 18:33:26 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7131E3A6CC2 for ; Sun, 29 Mar 2009 18:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.051 X-Spam-Level: * X-Spam-Status: No, score=1.051 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liEkWiRu-iiS for ; Sun, 29 Mar 2009 18:33:25 -0700 (PDT) Received: from sa.aa.arbor.net (unknown [204.181.64.1]) by core3.amsl.com (Postfix) with ESMTP id B32EE3A688C for ; Sun, 29 Mar 2009 18:33:25 -0700 (PDT) Received: from localhost (sa.aa.arbor.net [10.1.0.64]) by sa.aa.arbor.net (Postfix) with ESMTP id F26F516FFE for ; Sun, 29 Mar 2009 21:34:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at arbor.net Received: from sslvpn-109.ma.arbor.net (sslvpn-109.ma.arbor.net [10.2.15.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sa.aa.arbor.net (Postfix) with ESMTP id 97C2216FEC for ; Sun, 29 Mar 2009 21:34:21 -0400 (EDT) Message-Id: <24B404DE-1029-4F56-ADD3-E4B3F7E97096@tcb.net> From: Danny McPherson To: idr List In-Reply-To: <1477DEAE19DD884CB004730D0FD77FD7A43F54@misout7msgusr7e.ugd.att.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 29 Mar 2009 19:34:19 -0600 References: <49C906E6.9030904@raszuk.net> <1477DEAE19DD884CB004730D0FD77FD7A43F54@misout7msgusr7e.ugd.att.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 01:33:26 -0000 On Mar 28, 2009, at 10:54 AM, UTTARO, JAMES, ATTLABS wrote: > I do not agree. MED is a tool that is used to signal preference > between > two AS domains... It's a really bad idea to compare MEDs between two different "AS domains", for many reasons. Perhaps most important, is that if IGP metrics aren't normalized (which they'll never be unless you own all the domains) between them then you'll end up always picking one peer for all path selections. This was especially obvious when IS-IS had only 10 bits of path metric space, while OSPF had ++32 - and MEDs were adapted from cumulative IGP link metrics - the big guys that ran IS-IS picked up all the traffic by default. Ohh, and MEDs are broken for MANY other reasons, e.g.: www.tcb.net/Apricot-2004/Apricot-2004-MEDS.ppt -danny From enkechen@cisco.com Sun Mar 29 21:46:52 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB743A6A55 for ; Sun, 29 Mar 2009 21:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5EvmhMaSp1j for ; Sun, 29 Mar 2009 21:46:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 071DB3A6A4C for ; Sun, 29 Mar 2009 21:46:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,444,1233532800"; d="scan'208";a="276424631" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2009 04:47:48 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2U4lmt6006249; Sun, 29 Mar 2009 21:47:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2U4lmId028014; Mon, 30 Mar 2009 04:47:48 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Mar 2009 21:47:48 -0700 Received: from [10.21.115.129] ([10.21.115.129]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Mar 2009 21:47:48 -0700 Message-ID: <49D04EF4.4020608@cisco.com> Date: Sun, 29 Mar 2009 21:47:48 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Danny McPherson References: <49C906E6.9030904@raszuk.net> <1477DEAE19DD884CB004730D0FD77FD7A43F54@misout7msgusr7e.ugd.att.com> <24B404DE-1029-4F56-ADD3-E4B3F7E97096@tcb.net> In-Reply-To: <24B404DE-1029-4F56-ADD3-E4B3F7E97096@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2009 04:47:48.0310 (UTC) FILETIME=[ACB83F60:01C9B0F2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1322; t=1238388468; x=1239252468; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Idr]=20draft-rosen-idr-aigp-00 |Sender:=20; bh=vcjYKajIQVoacvFut3T1ykzjli+fkvAo6zjcN5EvvsM=; b=SGaKISzV8VyCHravBdsmRg90kuXet7vlJ1vUU+K07Qa7J0H3jZOrfrHzpa t4XmGGZ4iv1hHGndhMLXC3ZG6EtEB8iac7Mw89zHxkUpCMLxSBU20nDYaVS6 4aqS6lGrfeoPROap2yC6k6MvR65CcLOpIVXUzMhhOT7M6y4ieZKkY=; Authentication-Results: sj-dkim-1; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: idr List Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 04:46:52 -0000 Hi, folks: I do not think that the suggestion is for comparing MEDs from different ASes in general. Here we are talking about the case where several ASes act like one entity. There should be config knobs to make the MEDs accumulative, and also comparable within the entity. -- Enke Danny McPherson wrote: > > On Mar 28, 2009, at 10:54 AM, UTTARO, JAMES, ATTLABS wrote: > >> I do not agree. MED is a tool that is used to signal preference between >> two AS domains... > > It's a really bad idea to compare MEDs between two > different "AS domains", for many reasons. Perhaps > most important, is that if IGP metrics aren't normalized > (which they'll never be unless you own all the domains) > between them then you'll end up always picking one > peer for all path selections. > > This was especially obvious when IS-IS had only 10 bits > of path metric space, while OSPF had ++32 - and MEDs were > adapted from cumulative IGP link metrics - the big guys > that ran IS-IS picked up all the traffic by default. > > Ohh, and MEDs are broken for MANY other reasons, e.g.: > > www.tcb.net/Apricot-2004/Apricot-2004-MEDS.ppt > > -danny > > > > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From danny@tcb.net Sun Mar 29 22:48:08 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3ED3A6C12 for ; Sun, 29 Mar 2009 22:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.051 X-Spam-Level: * X-Spam-Status: No, score=1.051 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grMSR+BBEFU6 for ; Sun, 29 Mar 2009 22:48:08 -0700 (PDT) Received: from sa.aa.arbor.net (unknown [204.181.64.1]) by core3.amsl.com (Postfix) with ESMTP id 3F12B3A6BD1 for ; Sun, 29 Mar 2009 22:47:56 -0700 (PDT) Received: from localhost (sa.aa.arbor.net [10.1.0.64]) by sa.aa.arbor.net (Postfix) with ESMTP id 6BBC016FFE; Mon, 30 Mar 2009 01:48:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at arbor.net Received: from sslvpn-109.ma.arbor.net (sslvpn-109.ma.arbor.net [10.2.15.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sa.aa.arbor.net (Postfix) with ESMTP id 678A016FEC; Mon, 30 Mar 2009 01:48:52 -0400 (EDT) Message-Id: <67843988-CBEF-4E91-B4D9-CA0733C51FD1@tcb.net> From: Danny McPherson To: Enke Chen In-Reply-To: <49D04EF4.4020608@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 29 Mar 2009 23:48:50 -0600 References: <49C906E6.9030904@raszuk.net> <1477DEAE19DD884CB004730D0FD77FD7A43F54@misout7msgusr7e.ugd.att.com> <24B404DE-1029-4F56-ADD3-E4B3F7E97096@tcb.net> <49D04EF4.4020608@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: idr List Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 05:48:09 -0000 On Mar 29, 2009, at 10:47 PM, Enke Chen wrote: > Hi, folks: > > I do not think that the suggestion is for comparing MEDs from > different ASes in general. Here we are talking about the case where > several ASes act like one entity. There should be config knobs to > make the MEDs accumulative, and also comparable within the entity. Yes, I agree with you recommendation Enke. -danny From jsw@inconcepts.biz Mon Mar 30 00:06:31 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239743A6D0A for ; Mon, 30 Mar 2009 00:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.68 X-Spam-Level: ** X-Spam-Status: No, score=2.68 tagged_above=-999 required=5 tests=[AWL=-1.481, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+yG0VpZ4KFK for ; Mon, 30 Mar 2009 00:06:30 -0700 (PDT) Received: from odyssey.inconcepts.biz (unknown [69.31.82.162]) by core3.amsl.com (Postfix) with SMTP id 399F33A6A46 for ; Mon, 30 Mar 2009 00:06:30 -0700 (PDT) Received: (qmail 25018 invoked from network); 30 Mar 2009 07:07:27 -0000 Received: from 96-28-163-106.dhcp.insightbb.com (HELO ?96.28.163.106?) (96.28.163.106) by colo-69-31-82-163.pilosoft.com with SMTP; 30 Mar 2009 07:07:27 -0000 From: Jeff S Wheeler To: idr@ietf.org In-Reply-To: <49CEC525.9040306@raszuk.net> References: <49C906E6.9030904@raszuk.net> <1477DEAE19DD884CB004730D0FD77FD7A43F54@misout7msgusr7e.ugd.att.com> <49CEC525.9040306@raszuk.net> Content-Type: text/plain Organization: Innovative Network Concepts LLC Date: Mon, 30 Mar 2009 03:10:20 -0400 Message-Id: <1238397020.31558.53.camel@guardian.inconcepts.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 07:06:31 -0000 On Sat, 2009-03-28 at 17:47 -0700, Robert Raszuk wrote: > * I think that making new attribute is clean indeed, but a bit risky to > touch your best path selection algorithm each time new attribute is > invented to influence best path decision. How do you propose to make the algorithm aware of future attributes that have not been invented yet? If I want to do bestpath decision based on who has the coolest ASCII-art in their advertisement, just assuming that I have an army of stick-man art critics in my basement, how can you write spec or software to anticipate that need until I thought of it? > is exactly as you require in your case. Yes it would need to accumulate > MEDs metrics on the AS boundaries, but this is the same as adding new > values to the new to be deployed AIGP attribute. This is kinda being done on an inter-domain basis by some at least one major tier-2 today (you know who you are, and may have already taken credit for it on the list without my notice.) Some vendors support bestpath comparisons based on med+igp with arithmetic knobs now. And as we all know, there is the always-compare-med feature. On Sun, 2009-03-29 at 21:47 -0700, Enke Chen wrote: > act like one entity. There should be config knobs to make the MEDs > accumulative, and also comparable within the entity. There are on some platforms, see above. I think IOS-XR is one platform where this is possible, in fact. JUNOS can do it. _____________________________________________________ / Jeff S Wheeler +1-212-981-0607 \ \ Sr Network Operator / Innovative Network Concepts / ----------------------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || From robert@raszuk.net Mon Mar 30 00:13:17 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FDCE3A693B for ; Mon, 30 Mar 2009 00:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNQ1qD3nQZmh for ; Mon, 30 Mar 2009 00:13:16 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 538EB3A683E for ; Mon, 30 Mar 2009 00:13:16 -0700 (PDT) Received: (qmail 17117 invoked by uid 399); 30 Mar 2009 07:14:13 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.10.85) by mail37.opentransfer.com with SMTP; 30 Mar 2009 07:14:13 -0000 Message-ID: <49D0713F.2020207@raszuk.net> Date: Mon, 30 Mar 2009 00:14:07 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jeff S Wheeler References: <49C906E6.9030904@raszuk.net> <1477DEAE19DD884CB004730D0FD77FD7A43F54@misout7msgusr7e.ugd.att.com> <49CEC525.9040306@raszuk.net> <1238397020.31558.53.camel@guardian.inconcepts.net> In-Reply-To: <1238397020.31558.53.camel@guardian.inconcepts.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 07:13:17 -0000 Hi Jeff, >> * I think that making new attribute is clean indeed, but a bit risky to >> touch your best path selection algorithm each time new attribute is >> invented to influence best path decision. > > How do you propose to make the algorithm aware of future attributes that > have not been invented yet? If I want to do bestpath decision based on > who has the coolest ASCII-art in their advertisement, just assuming that > I have an army of stick-man art critics in my basement, how can you > write spec or software to anticipate that need until I thought of it? http://tools.ietf.org/html/draft-retana-bgp-custom-decision-00 This document defines a new Extended Community [EXT_COMM], called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. ... The network administrator may use the Cost Community to assign a value to a path originated or learned by a peer in any part of the local domain. The Point of Insertion may also be specified using the values defined in the IANA registry [BGP_PAR] or this document. If a BGP speaker receives a path that contains the Cost Community, it MUST consider its value at the Point of Insertion specified, when calculating the best path [RFC1771]. R. From erosen@cisco.com Mon Mar 30 07:29:20 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B31628C0EF for ; Mon, 30 Mar 2009 07:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp-lq48Y2j1V for ; Mon, 30 Mar 2009 07:29:16 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8E8AA3A6B97 for ; Mon, 30 Mar 2009 07:29:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,446,1233532800"; d="scan'208";a="40600445" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 Mar 2009 14:30:14 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2UEUEeF000659; Mon, 30 Mar 2009 10:30:14 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2UEUDKm005928; Mon, 30 Mar 2009 14:30:14 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n2UEUD0o003549; Mon, 30 Mar 2009 10:30:13 -0400 To: robert@raszuk.net In-reply-to: Your message of Sat, 28 Mar 2009 17:47:33 -0700. <49CEC525.9040306@raszuk.net> Date: Mon, 30 Mar 2009 10:30:13 -0400 Message-ID: <3548.1238423413@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1320; t=1238423414; x=1239287414; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20[Idr]=20draft-rosen-idr-aigp-00=20 |Sender:=20 |To:=20robert@raszuk.net; bh=70kNQFpRn523ym9i3cWKfSFsB5Q0uQlU/PYS76pGzL0=; b=VB2tbk5jGmwXSRaHOTwSJV3G2wTkrleUevgVVw7XGGnuqeaNSGJjKiAacQ QxMlJ3rNuOI3kLwgWeprpNsMnLbX7QTRP64hPmen1ztBPWtaNKXVhpZESwhX v6pIGsKfbA; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: idr Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 30 Mar 2009 14:29:20 -0000 > cost community where designed to be common tool to modify the best path > selection on as needed basis The Cost Community i-d expired about six years ago, so I really don't know why it's being brought up. However, I will say that I think the idea of having a "common tool to modify the best path selection on an as needed basis" is not a very good idea. > a bit risky to touch your best path selection algorithm each time new > attribute is invented Yes, much less risky to allow arbitrary changes by allowing new values to be inserted at any arbitrary place ;-) Maybe we should generalize more and use the "advisory message" to pass a C program specifying a new decision process ;-) > Yes it would need to accumulate MEDs metrics on the AS boundaries Really, the MED has enough problems as it is, it doesn't need to be overloaded with yet more functions. I do not think it simplifies things to take a well-defined function and try to achieve it by using an ad hoc combination of other attributes that are already known to be problematic. > in deployments in other customer > networks when AIGP support is partial in the mesh of ASes it is quite > obvious that it may lead to permanent loops Please give an example of such a loop. From robert@raszuk.net Mon Mar 30 07:55:21 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8563A6A29 for ; Mon, 30 Mar 2009 07:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw7WewsfcIQU for ; Mon, 30 Mar 2009 07:55:17 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id C12893A68B1 for ; Mon, 30 Mar 2009 07:55:17 -0700 (PDT) Received: (qmail 10942 invoked by uid 399); 30 Mar 2009 14:56:15 -0000 Received: from unknown (HELO ?192.168.1.100?) (83.5.221.194) by mail37.opentransfer.com with SMTP; 30 Mar 2009 14:56:15 -0000 Message-ID: <49D0DD89.4070509@raszuk.net> Date: Mon, 30 Mar 2009 07:56:09 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: erosen@cisco.com References: <3548.1238423413@erosen-linux> In-Reply-To: <3548.1238423413@erosen-linux> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 14:55:21 -0000 Hi Eric, > The Cost Community i-d expired about six years ago, so I really don't know > why it's being brought up. While the draft did in fact expired there is at least one major shipping implementations utilizing it today. > Maybe we should generalize more and use the "advisory message" to pass a C > program specifying a new decision process ;-) LOL ! >> Yes it would need to accumulate MEDs metrics on the AS boundaries > > Really, the MED has enough problems as it is, it doesn't need to be > overloaded with yet more functions. I did not think MED needs to be modified. It would just need to pass it's carried metric into ext community. Such community would have exactly the same properties as AIGP attribute. > I do not think it simplifies things to take a well-defined function and try > to achieve it by using an ad hoc combination of other attributes that are > already known to be problematic. And I don't think we need to invent new tools if existing tools can do the same job. At min I would expect a paragraph in the spec explaining the choice of new clean AIGP attribute as opposed to use combination of existing tools. >> in deployments in other customer >> networks when AIGP support is partial in the mesh of ASes it is quite >> obvious that it may lead to permanent loops > > Please give an example of such a loop. If you set AIGP attribute outside of specified rules (ie for example after reviving given prefix on EBGP session due to misconfig or bug) it is pretty trival to see the loop. Rather then shipping the fragile attribute I was just suggesting to add 4 more octets of either src rtr_id (the one which at the redistribution appends AIGP attribute) or src AS number. An additional rule in the best path run would be to only compare AIGP attributes for a given net with equal such 4 octet field. IMHO that could make the feature more robust. Cheers, R. From erosen@cisco.com Mon Mar 30 09:12:21 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B843A6D08 for ; Mon, 30 Mar 2009 09:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kSGtO6meSGz for ; Mon, 30 Mar 2009 09:12:20 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 10F473A6AA1 for ; Mon, 30 Mar 2009 09:12:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,447,1233532800"; d="scan'208";a="40565366" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2009 16:13:17 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2UGDHce001753; Mon, 30 Mar 2009 12:13:17 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2UGDHKq011197; Mon, 30 Mar 2009 16:13:17 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n2UGDHsQ004519; Mon, 30 Mar 2009 12:13:17 -0400 To: robert@raszuk.net In-reply-to: Your message of Mon, 30 Mar 2009 07:56:09 -0700. <49D0DD89.4070509@raszuk.net> Date: Mon, 30 Mar 2009 12:13:17 -0400 Message-ID: <4518.1238429597@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=218; t=1238429597; x=1239293597; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20[Idr]=20draft-rosen-idr-aigp-00=20 |Sender:=20 |To:=20robert@raszuk.net; bh=+Pxr1+t274jYXH90nsWcAFdYsdrs4aDto+rmQzm9yIk=; b=MfMnUieHKmJYTppcFfLBdsQOkvSDj1PkM05bPn6gWCJeRWrMXYpWtl5ysl DGq1erFH8jgRPBiwieN5SQbsc3BXNQXrIxMgcJtqFS6PR38KrOvzfduquw7o HR9vRq/OqY; Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: idr , erosen@cisco.com Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 30 Mar 2009 16:12:21 -0000 > If you set AIGP attribute outside of specified rules (ie for example > after reviving given prefix on EBGP session due to misconfig or bug) it > is pretty trival to see the loop. Please provide an example. From robert@raszuk.net Mon Mar 30 10:32:30 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E359E3A6D4A for ; Mon, 30 Mar 2009 10:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzlD7CPsYzAv for ; Mon, 30 Mar 2009 10:32:30 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 05E993A6B03 for ; Mon, 30 Mar 2009 10:32:29 -0700 (PDT) Received: (qmail 31165 invoked by uid 399); 30 Mar 2009 17:33:28 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.10.85) by mail37.opentransfer.com with SMTP; 30 Mar 2009 17:33:28 -0000 Message-ID: <49D10261.5080103@raszuk.net> Date: Mon, 30 Mar 2009 10:33:21 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: erosen@cisco.com References: <4518.1238429597@erosen-linux> In-Reply-To: <4518.1238429597@erosen-linux> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 17:32:31 -0000 Hi Eric, Apologies for my ASCII art :( >> If you set AIGP attribute outside of specified rules (ie for example >> after reviving given prefix on EBGP session due to misconfig or bug) it >> is pretty trival to see the loop. > > Please provide an example. For example: ASBR3a --1--ASBR3b | \ _1_/ | 1 _/ | | / \ | ASBR2 x x | \ \ | 10 x_ \ | | \_ \ | ASBR1a ---- ASBR1b | A/z Let's assume the above. AS3 represented by ASBR3a & 3b are setting AIGP attribute to 1 on reception of advertisements from ASBR1b. Since having the sttribute set is per specification by default better from not having the attribute at all ASBR3a/3b as well as is above local preference check in the best path between ASBR3a/3b/2 the loop will form. If we would add the validation that only AIGP values originated from the same AS are comparable and if not they are not to be considered at all it would make the feature safer to deploy and use. The proposed placement of AIGP best path influence check above local pref makes it pretty much an absolute criteria. Especially that even EBGP vs IBGP check which is much lower would be skipped. Cheers, R. From erosen@cisco.com Mon Mar 30 11:15:53 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1803A6C10 for ; Mon, 30 Mar 2009 11:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvvrL6lgPBW9 for ; Mon, 30 Mar 2009 11:15:48 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5F90E3A69D1 for ; Mon, 30 Mar 2009 11:15:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,447,1233532800"; d="scan'208";a="40574893" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2009 18:16:46 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2UIGknr002496; Mon, 30 Mar 2009 14:16:46 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2UIGjrj022256; Mon, 30 Mar 2009 18:16:45 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n2UIGjWV005920; Mon, 30 Mar 2009 14:16:45 -0400 To: robert@raszuk.net In-reply-to: Your message of Mon, 30 Mar 2009 10:33:21 -0700. <49D10261.5080103@raszuk.net> Date: Mon, 30 Mar 2009 14:16:45 -0400 Message-ID: <5919.1238437005@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=400; t=1238437006; x=1239301006; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20[Idr]=20draft-rosen-idr-aigp-00=20 |Sender:=20 |To:=20robert@raszuk.net; bh=9PgN847f4cq2lNuoDoN85sE5wwN9CuE7ovV1WMvid9o=; b=bAipb5rrsILHSMHBzw1rV17EdNJfoA8gB3h51yNgoLW38F1xMsqiR57h3l eJQq567f8fFuZxY1xphdB+uU74pgLp6lE+1EbfBCiM+WilUvQ9vUk7MirCE3 GpdAbTE3oA; Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: idr , erosen@cisco.com Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 30 Mar 2009 18:15:53 -0000 > AS3 represented by ASBR3a & 3b are setting AIGP attribute to 1 on > reception of advertisements from ASBR1b. Section 3.3.1: A BGP speaker MUST NOT add the AIGP attribute to any route whose path leads outside the AS to which the BGP speaker belongs. Section 4.1: the AS_PATH continues to be used to prevent consideration of routes that traverse an AS more than once. From robert@raszuk.net Mon Mar 30 11:22:26 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5993A6B42 for ; Mon, 30 Mar 2009 11:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5P9Lg6BxQu3 for ; Mon, 30 Mar 2009 11:22:25 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id A282C3A69D1 for ; Mon, 30 Mar 2009 11:22:25 -0700 (PDT) Received: (qmail 12151 invoked by uid 399); 30 Mar 2009 18:23:23 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.10.85) by mail37.opentransfer.com with SMTP; 30 Mar 2009 18:23:23 -0000 Message-ID: <49D10E14.3020205@raszuk.net> Date: Mon, 30 Mar 2009 11:23:16 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: erosen@cisco.com References: <5919.1238437005@erosen-linux> In-Reply-To: <5919.1238437005@erosen-linux> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 18:22:26 -0000 Eric, > Section 3.3.1: > > A BGP speaker MUST NOT add the AIGP attribute to any route whose path > leads outside the AS to which the BGP speaker belongs. You are quoting the spec .. I read it. I was talking about misconfiguration and bugs. In the other emial I said: "If you set AIGP attribute outside of specified rules (ie for example after reviving given prefix on EBGP session due to misconfig or bug) it is pretty trival to see the loop." I agree we should not get into every corner case paranoia, but making protocol robust for basic potential problems seems for me like not a big incremental effort. > Section 4.1: > > the AS_PATH continues to be used to prevent > consideration of routes that traverse an AS more than once. I don't understand this one. If AIGP is above local pref and local pref is step #2 in best path once we tie break at AIGP how do we continute to compare AS_PATH ? Cheers, R. >> AS3 represented by ASBR3a & 3b are setting AIGP attribute to 1 on >> reception of advertisements from ASBR1b. > > Section 3.3.1: > > A BGP speaker MUST NOT add the AIGP attribute to any route whose path > leads outside the AS to which the BGP speaker belongs. > > Section 4.1: > > the AS_PATH continues to be used to prevent > consideration of routes that traverse an AS more than once. > > From erosen@cisco.com Mon Mar 30 11:51:23 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6C33A6C62 for ; Mon, 30 Mar 2009 11:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMms8DRi+VRc for ; Mon, 30 Mar 2009 11:51:22 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1FC773A6A36 for ; Mon, 30 Mar 2009 11:51:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,447,1233532800"; d="scan'208";a="40580021" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Mar 2009 18:52:14 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2UIqEJ8022060; Mon, 30 Mar 2009 14:52:14 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2UIqDfV003879; Mon, 30 Mar 2009 18:52:13 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n2UIqDu2006218; Mon, 30 Mar 2009 14:52:13 -0400 To: robert@raszuk.net In-reply-to: Your message of Mon, 30 Mar 2009 11:23:16 -0700. <49D10E14.3020205@raszuk.net> Date: Mon, 30 Mar 2009 14:52:13 -0400 Message-ID: <6217.1238439133@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=677; t=1238439134; x=1239303134; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20[Idr]=20draft-rosen-idr-aigp-00=20 |Sender:=20 |To:=20robert@raszuk.net; bh=snanb3S0Mm5KgYN653fbBTk5d0RHwFw2Hz8MdQO2R7Y=; b=Mg/No46iqFuaeWpHVokb8JBNplp8Cnqb3TuDc8CO+7p6nKXhCn4IwfwVkI hxDPlbF3YAKybr2d1SN4CMbQLMFDGhOUHKWDXqfVJJBRTiMxMUOZcuGf1nU1 xJJeEYBxKa; Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: idr , erosen@cisco.com Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 30 Mar 2009 18:51:23 -0000 > I was talking about misconfiguration and bugs I'm not sure I see how a misconfiguration by itself can cause a loop. It's always possible to imagine a bug that will cause a loop. > If AIGP is above local pref and local pref is step #2 in best path once we > tie break at AIGP how do we continue to compare AS_PATH ? The intention is that (a) AIGP trumps AS_PATH length, but (b) if a route has an AS_PATH indicating a loop, then the route is not considered. (It is possible that a least latency path will exit an AS and then re-enter it, but the intention is not to use such paths.) Do you think this needs to be clarified in the spec? From robert@raszuk.net Mon Mar 30 12:01:43 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C3E3A6D63 for ; Mon, 30 Mar 2009 12:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRu8o7VKYG5P for ; Mon, 30 Mar 2009 12:01:43 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id AD38D3A6D4F for ; Mon, 30 Mar 2009 12:01:34 -0700 (PDT) Received: (qmail 16545 invoked by uid 399); 30 Mar 2009 19:02:32 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.10.85) by mail37.opentransfer.com with SMTP; 30 Mar 2009 19:02:32 -0000 Message-ID: <49D11741.9090305@raszuk.net> Date: Mon, 30 Mar 2009 12:02:25 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: erosen@cisco.com References: <6217.1238439133@erosen-linux> In-Reply-To: <6217.1238439133@erosen-linux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: idr Subject: Re: [Idr] draft-rosen-idr-aigp-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 19:01:44 -0000 Hi Eric, > I'm not sure I see how a misconfiguration by itself can cause a loop. It's > always possible to imagine a bug that will cause a loop. If appending AIGP can be done by policy misconfig could hurt as well. >> If AIGP is above local pref and local pref is step #2 in best path once we >> tie break at AIGP how do we continue to compare AS_PATH ? > > The intention is that (a) AIGP trumps AS_PATH length, but (b) if a route has > an AS_PATH indicating a loop, then the route is not considered. (It is > possible that a least latency path will exit an AS and then re-enter it, but > the intention is not to use such paths.) Do you think this needs to be > clarified in the spec? But that has nothing to do with best path selection ... Looped paths are not even considered for best path comparison. From some vendor's public document: "Paths from an external BGP (eBGP) neighbor if the local autonomous system (AS) appears in the AS_PATH: Such paths are denied upon ingress into the router and are not even installed in the BGP Routing Information Base (RIB). The same applies to any path that is denied by a routing policy that is implemented via access, prefix, AS_PATH, or community lists, unless you have configured soft−reconfiguration inbound for the neighbor." So I think spec should remove the AS_PATH section from 4.1 to make it clear and to match the common implementations practices. Cheers, R. From rex@juniper.net Tue Mar 31 10:40:20 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF9A3A68BA for ; Tue, 31 Mar 2009 10:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJY3udK8PD+n for ; Tue, 31 Mar 2009 10:40:19 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 84A543A6825 for ; Tue, 31 Mar 2009 10:40:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSdJVvtu1LZNpicKbVzHzNwkW7bQe9CIp@postini.com; Tue, 31 Mar 2009 10:41:19 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 31 Mar 2009 10:40:17 -0700 From: Rex Fernando To: "'idr@ietf.org'" Date: Tue, 31 Mar 2009 10:40:17 -0700 Thread-Topic: draft-marques-idr-best-external-01.txt as IDR WG doc Thread-Index: AcmyJ74Yp/N6WHrYTGmY+iKPIWbFGQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 17:40:20 -0000 The authors would like to request that draft-marques-idr-best-external-01.t= xt be adopted as an IDR WG document. It was presented in IDR in the Minneap= olis IETF. From yakov@juniper.net Tue Mar 31 11:00:06 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FADE3A687C for ; Tue, 31 Mar 2009 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DepftcFqsNm9 for ; Tue, 31 Mar 2009 11:00:05 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id C90A53A6817 for ; Tue, 31 Mar 2009 11:00:05 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSdJaYefUaL5zIeuGUFqTvy91HuDjoEhE@postini.com; Tue, 31 Mar 2009 11:01:05 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 31 Mar 2009 10:57:32 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 10:57:32 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 10:57:32 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 10:57:32 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2VHvVM89688 for ; Tue, 31 Mar 2009 10:57:31 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200903311757.n2VHvVM89688@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8957.1238522251.1@juniper.net> Date: Tue, 31 Mar 2009 10:57:31 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 31 Mar 2009 17:57:32.0014 (UTC) FILETIME=[2A0570E0:01C9B22A] Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 18:00:06 -0000 Folks, Please comment on the attached request. The deadline for comments is April 14, 2009. If anyone is aware of the IPR related to the draft, please follow the procedurs of rfc3979. Yakov. ------- Forwarded Message Date: Tue, 31 Mar 2009 10:40:17 -0700 From: Rex Fernando To: "'idr@ietf.org'" Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc The authors would like to request that draft-marques-idr-best-external-01.txt b e adopted as an IDR WG document. It was presented in IDR in the Minneapolis IETF. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message From jgs@juniper.net Tue Mar 31 11:04:31 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE233A67D1 for ; Tue, 31 Mar 2009 11:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYdy0LOQ-XXp for ; Tue, 31 Mar 2009 11:04:30 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 7A0113A6D42 for ; Tue, 31 Mar 2009 11:04:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSdJbafxtwsPgWBGc+QXJv7Gl+UqeLGxa@postini.com; Tue, 31 Mar 2009 11:05:30 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 31 Mar 2009 11:02:29 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 11:02:28 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 11:02:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 11:02:28 -0700 Received: from sa-nc-common2-189.static.jnpr.net (sa-nc-common2-189.static.jnpr.net [172.23.9.189]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n2VI2RM93461; Tue, 31 Mar 2009 11:02:27 -0700 (PDT) (envelope-from jgs@juniper.net) Message-ID: From: "John G. Scudder" To: Yakov Rekhter In-Reply-To: <200903311757.n2VHvVM89688@magenta.juniper.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 31 Mar 2009 14:02:26 -0400 References: <200903311757.n2VHvVM89688@magenta.juniper.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 31 Mar 2009 18:02:28.0070 (UTC) FILETIME=[DA7C0060:01C9B22A] Cc: idr@ietf.org Subject: Re: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 18:04:32 -0000 In favor. --John On Mar 31, 2009, at 1:57 PM, Yakov Rekhter wrote: > Folks, > > Please comment on the attached request. The deadline for comments > is April 14, 2009. > > If anyone is aware of the IPR related to the draft, please follow > the procedurs of rfc3979. > > Yakov. > ------- Forwarded Message > > Date: Tue, 31 Mar 2009 10:40:17 -0700 > From: Rex Fernando > To: "'idr@ietf.org'" > Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc > > > The authors would like to request that > draft-marques-idr-best-external-01.txt b e adopted as an IDR WG > document. It was presented in IDR in the Minneapolis IETF. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jguichar@cisco.com Tue Mar 31 11:05:08 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9AB28C13E for ; Tue, 31 Mar 2009 11:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2BFHeYjZtBU for ; Tue, 31 Mar 2009 11:05:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A98783A6956 for ; Tue, 31 Mar 2009 11:05:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,303,1235952000"; d="scan'208,217";a="40688718" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Mar 2009 18:06:06 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2VI66ho024730; Tue, 31 Mar 2009 14:06:06 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2VI66um003082; Tue, 31 Mar 2009 18:06:06 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 14:06:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B22B.5C4F398E" Date: Tue, 31 Mar 2009 14:06:05 -0400 Message-ID: <9A3A6AC97A8CF44DACD99DC00BEC235A037B17A8@xmb-rtp-203.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-marques-idr-best-external-01.txt as IDR WG doc Thread-Index: AcmyJ74Yp/N6WHrYTGmY+iKPIWbFGQAA55TJ From: "Jim Guichard (jguichar)" To: "Rex Fernando" , X-OriginalArrivalTime: 31 Mar 2009 18:06:06.0340 (UTC) FILETIME=[5C955C40:01C9B22B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1906; t=1238522766; x=1239386766; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jguichar@cisco.com; z=From:=20=22Jim=20Guichard=20(jguichar)=22=20 |Subject:=20RE=3A=20[Idr]=20draft-marques-idr-best-external -01.txt=20as=20IDR=20WG=20doc |Sender:=20 |To:=20=22Rex=20Fernando=22=20,=20; bh=G6S4YJr+x4HtHVCOtPCRuOTlQpZpkHKJF2GrDHgJUlU=; b=XW6fFRvIwe5Wo9+vhASYr/T8s/uL/TsMBuAK20YRFniOuQ0rA6RdLxXD4V 9ElS2Dy1ZsIKrwfoaSHrsEIgVpSB8O/fE/LfoDLy1Me33C8EOFmpgY5eD8yE cqbeZhW61L; Authentication-Results: rtp-dkim-1; header.From=jguichar@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 18:05:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B22B.5C4F398E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. -----Original Message----- From: Rex Fernando [mailto:rex@juniper.net] Sent: Tuesday, March 31, 2009 01:41 PM Eastern Standard Time To: 'idr@ietf.org' Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc The authors would like to request that = draft-marques-idr-best-external-01.txt be adopted as an IDR WG document. = It was presented in IDR in the Minneapolis IETF. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------_=_NextPart_001_01C9B22B.5C4F398E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Idr] draft-marques-idr-best-external-01.txt as IDR WG = doc

Support.



 -----Original Message-----
From:   Rex Fernando [mailto:rex@juniper.net]
Sent:   Tuesday, March 31, 2009 01:41 PM Eastern Standard = Time
To:     'idr@ietf.org'
Subject:        [Idr] = draft-marques-idr-best-external-01.txt as IDR WG doc


The authors would like to request that = draft-marques-idr-best-external-01.txt be adopted as an IDR WG document. = It was presented in IDR in the Minneapolis IETF.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/m= ailman/listinfo/idr

------_=_NextPart_001_01C9B22B.5C4F398E-- From uttaro@att.com Tue Mar 31 11:24:18 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB4F3A69D2 for ; Tue, 31 Mar 2009 11:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.348 X-Spam-Level: X-Spam-Status: No, score=-106.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciGolrHybVqQ for ; Tue, 31 Mar 2009 11:24:17 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 652C23A6956 for ; Tue, 31 Mar 2009 11:24:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: uttaro@att.com X-Msg-Ref: server-8.tower-129.messagelabs.com!1238523915!29827635!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 8688 invoked from network); 31 Mar 2009 18:25:16 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-8.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Mar 2009 18:25:16 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2VIPECK011101; Tue, 31 Mar 2009 14:25:15 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2VIP9NL011046; Tue, 31 Mar 2009 14:25:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Mar 2009 14:25:08 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD701E9B73C@misout7msgusr7e.ugd.att.com> In-Reply-To: <200903311757.n2VHvVM89688@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc Thread-Index: AcmyKrLCU9Vqy5x6RZ6oUrfvQ/ZHMwAA0v+w References: <200903311757.n2VHvVM89688@magenta.juniper.net> From: "UTTARO, JAMES, ATTLABS" To: "Yakov Rekhter" , Subject: Re: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 18:24:18 -0000 Support=20 Jim Uttaro=20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Yakov Rekhter Sent: Tuesday, March 31, 2009 1:58 PM To: idr@ietf.org Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc Folks, Please comment on the attached request. The deadline for comments is April 14, 2009. If anyone is aware of the IPR related to the draft, please follow the procedurs of rfc3979. Yakov. ------- Forwarded Message Date: Tue, 31 Mar 2009 10:40:17 -0700 From: Rex Fernando To: "'idr@ietf.org'" Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc The authors would like to request that draft-marques-idr-best-external-01.txt b e adopted as an IDR WG document. It was presented in IDR in the Minneapolis IETF. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From enkechen@cisco.com Tue Mar 31 11:29:35 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44483A6A36 for ; Tue, 31 Mar 2009 11:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-mzp3Xz2SbT for ; Tue, 31 Mar 2009 11:29:35 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EA1073A6953 for ; Tue, 31 Mar 2009 11:29:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,303,1235952000"; d="scan'208";a="148764744" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2009 18:30:34 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2VIUYNL018472; Tue, 31 Mar 2009 11:30:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2VIUYYa007596; Tue, 31 Mar 2009 18:30:34 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 11:30:34 -0700 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 11:30:33 -0700 Message-ID: <49D26149.1060905@cisco.com> Date: Tue, 31 Mar 2009 11:30:33 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Yakov Rekhter References: <200903311757.n2VHvVM89688@magenta.juniper.net> In-Reply-To: <200903311757.n2VHvVM89688@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Mar 2009 18:30:33.0960 (UTC) FILETIME=[C75A6680:01C9B22E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1681; t=1238524234; x=1239388234; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Idr]=20=20draft-marques-idr-best-exter nal-01.txt=20as=20IDR=20WG=20doc |Sender:=20; bh=O9RgBXKrQfh414nn/oMUpJFNvO+wu27rlRFOQQwvdcg=; b=DXjRvAXhLtOqnJhtP9n/eYt9zb28wws8PAnRtLo7sUViVqLQ2/LLjqYSpR GozmEuOvTMRcGgkRTI/OE7e4C0swrCKIc4tGR5FHwn83nhIo1XiOJirHFCt1 xoIQIFc05F; Authentication-Results: sj-dkim-2; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: idr@ietf.org Subject: Re: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 18:29:36 -0000 Hi, folks: I just submitted a third-party patent disclosure related to the draft: US Patent 7,502,332, granted March 10, 2009. ---------------------- The initial disclosure was reported in draft-chen-rr-oscillation-reduce-01.txt, dated June 2002: 6. Intellectual Property Considerations Redback Networks, Inc. may seek patent protection on some of the technology described in this Internet Draft. If technology in this document is adopted as a standard, Redback Networks agrees to license, on reasonable and non-discriminatory terms, any patent rights it obtains covering such technology to the extent necessary to comply with the standard. --------------------- -- Enke Yakov Rekhter wrote: > Folks, > > Please comment on the attached request. The deadline for comments > is April 14, 2009. > > If anyone is aware of the IPR related to the draft, please follow > the procedurs of rfc3979. > > Yakov. > ------- Forwarded Message > > Date: Tue, 31 Mar 2009 10:40:17 -0700 > From: Rex Fernando > To: "'idr@ietf.org'" > Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc > > > The authors would like to request that > draft-marques-idr-best-external-01.txt b e adopted as an IDR WG > document. It was presented in IDR in the Minneapolis IETF. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From bruno.decraene@orange-ftgroup.com Tue Mar 31 11:35:49 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04EA3A67FF for ; Tue, 31 Mar 2009 11:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWerM2RqvzTh for ; Tue, 31 Mar 2009 11:35:48 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 7523D3A68AA for ; Tue, 31 Mar 2009 11:35:47 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.192.128.42]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 20:36:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Mar 2009 20:36:48 +0200 Message-ID: <5A0FF108221C7C4E85738678804B567C073ECF6A@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc Thread-Index: AcmyKq65OUfv77zPSK+U2nECew4HBgABO2Vg References: <200903311757.n2VHvVM89688@magenta.juniper.net> From: To: , X-OriginalArrivalTime: 31 Mar 2009 18:36:45.0216 (UTC) FILETIME=[A4A39200:01C9B22F] Subject: Re: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 18:35:49 -0000 Support. > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Yakov Rekhter > Sent: Tuesday, March 31, 2009 7:58 PM > To: idr@ietf.org > Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc >=20 > Folks, >=20 > Please comment on the attached request. The deadline for comments > is April 14, 2009. >=20 > If anyone is aware of the IPR related to the draft, please follow > the procedurs of rfc3979. >=20 > Yakov. > ------- Forwarded Message >=20 > Date: Tue, 31 Mar 2009 10:40:17 -0700 > From: Rex Fernando > To: "'idr@ietf.org'" > Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc >=20 >=20 > The authors would like to request that > draft-marques-idr-best-external-01.txt b e adopted as an IDR WG > document. It was presented in IDR in the Minneapolis IETF. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From mprodrigues@juniper.net Wed Mar 25 10:30:19 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE0528C0F3 for ; Wed, 25 Mar 2009 10:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtmLBpMJ4Kca for ; Wed, 25 Mar 2009 10:30:17 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 8AED53A68AB for ; Wed, 25 Mar 2009 10:30:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKScpqWoiJQTM13GZ1KjB2DC6stNkln/4w@postini.com; Wed, 25 Mar 2009 10:31:10 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Wed, 25 Mar 2009 10:28:25 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 10:28:25 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 10:28:25 -0700 Received: from emailwf3.jnpr.net ([10.10.2.45]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 13:28:22 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 13:28:22 -0400 Message-ID: <295627243C91274CBCE3C52BBB7E3D86025530A1@emailwf3.jnpr.net> In-Reply-To: <49CA6334.9030100@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-scholl-idr-advisory-00 Thread-Index: Acmtaz4dai04+TZDQISi/XS8HSuHIAAAzEWw References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com><20090325164820.GO74388@ronin.4ever.de> <49CA6334.9030100@raszuk.net> From: Marco Rodrigues To: , "Elmar K. Bins" X-OriginalArrivalTime: 25 Mar 2009 17:28:22.0974 (UTC) FILETIME=[19089DE0:01C9AD6F] X-Mailman-Approved-At: Tue, 31 Mar 2009 11:46:59 -0700 Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:30:19 -0000 > Hi Elmar, >=20 > > - this isn't routing info being transmitted (anyone want to > > introduce the like in OSPF or ISIS?) and thus doesn't belong > > in BGP transmissions >=20 > Actually on this you are not fully right. The amount of non routing > information carried in IGPs today is huge :) Look at the mpls traffic > eng alone ... Thank you.=20 > Perhaps let's just do things right in BGP to start with. Why not to > define a BGP-CI (communication instance) and use it for exchange of such > advisory information without any impact to routing ? Are you suggesting another parallel connection between neighbors designed specifically to only carry communication information? Wouldn't one want to consider the scaling issues with this approach?=20 -mpr From elmi@detebe.org Thu Mar 26 03:28:13 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3989C3A6CE8 for ; Thu, 26 Mar 2009 03:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEMM3IioMaWA for ; Thu, 26 Mar 2009 03:28:12 -0700 (PDT) Received: from ronin.4ever.de (elmi4711-1-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:1108::2]) by core3.amsl.com (Postfix) with ESMTP id 21C9E3A69CB for ; Thu, 26 Mar 2009 03:28:02 -0700 (PDT) Received: from elmi by ronin.4ever.de with local (Exim 4.50 (FreeBSD)) id 1LmmpS-000O2z-7o; Thu, 26 Mar 2009 11:28:54 +0100 Date: Thu, 26 Mar 2009 11:28:54 +0100 From: "Elmar K. Bins" To: David Freedman Message-ID: <20090326102854.GV74388@ronin.4ever.de> References: <1BD38DD97E9BEB40A599BFCCED93CC7F04CDA4@EXVS01.claranet.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BD38DD97E9BEB40A599BFCCED93CC7F04CDA4@EXVS01.claranet.local> Organization: unorganized since 1789 X-Whisky: Knockando, extra old reserve X-Ncc-RegID: de.denic User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Tue, 31 Mar 2009 11:46:59 -0700 Cc: idr@ietf.org Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 10:28:13 -0000 Re David, david.freedman@uk.clara.net (David Freedman) wrote: > Sorry, it's quite late here, but to clarify, RFC4271 Ah, alright, got it. Thanks for the clarification. Elmar. PS: If non-terminal notifications are so important to operators, why were they not included in named RFC, meaning, why has the session termination not being made optional for certain cases? Was there discussion? (I missed it) From mprodrigues@juniper.net Tue Mar 31 11:40:13 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABBD3A67FF for ; Tue, 31 Mar 2009 11:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWKgCFYroWLE for ; Tue, 31 Mar 2009 11:40:12 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id A47983A6D9A for ; Tue, 31 Mar 2009 11:40:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSdJjx74J5NhmNEuqKk5UJ3sickfmfpWg@postini.com; Tue, 31 Mar 2009 11:41:12 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 31 Mar 2009 11:37:45 -0700 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 11:37:45 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 11:37:45 -0700 Received: from emailwf3.jnpr.net ([10.10.2.45]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 14:37:44 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Mar 2009 14:37:43 -0400 Message-ID: <295627243C91274CBCE3C52BBB7E3D86025E3B34@emailwf3.jnpr.net> In-Reply-To: <200903311757.n2VHvVM89688@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc Thread-Index: AcmyKq6gZNiOZhajTQmBltPqYfCFsQABRNlA References: <200903311757.n2VHvVM89688@magenta.juniper.net> From: Marco Rodrigues To: X-OriginalArrivalTime: 31 Mar 2009 18:37:44.0263 (UTC) FILETIME=[C7D56D70:01C9B22F] X-Mailman-Approved-At: Tue, 31 Mar 2009 11:46:59 -0700 Subject: Re: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 18:40:13 -0000 I support the WG adoption of this draft. -mpr > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Yakov Rekhter > Sent: Tuesday, March 31, 2009 1:58 PM > To: idr@ietf.org > Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc >=20 > Folks, >=20 > Please comment on the attached request. The deadline for comments > is April 14, 2009. >=20 > If anyone is aware of the IPR related to the draft, please follow > the procedurs of rfc3979. >=20 > Yakov. > ------- Forwarded Message >=20 > Date: Tue, 31 Mar 2009 10:40:17 -0700 > From: Rex Fernando > To: "'idr@ietf.org'" > Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc >=20 >=20 > The authors would like to request that > draft-marques-idr-best-external-01.txt b e adopted as an IDR WG > document. It was presented in IDR in the Minneapolis IETF. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Tue Mar 31 12:03:24 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DD63A6DB7 for ; Tue, 31 Mar 2009 12:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHLEO+fzOeGb for ; Tue, 31 Mar 2009 12:03:23 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id A41D53A6953 for ; Tue, 31 Mar 2009 12:03:23 -0700 (PDT) Received: (qmail 10902 invoked by uid 399); 31 Mar 2009 19:04:18 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.50.104) by mail37.opentransfer.com with SMTP; 31 Mar 2009 19:04:18 -0000 Message-ID: <49D2692E.6060407@raszuk.net> Date: Tue, 31 Mar 2009 12:04:14 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: idr References: <200903311757.n2VHvVM89688@magenta.juniper.net> In-Reply-To: <200903311757.n2VHvVM89688@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 19:03:24 -0000 Support. Thx, R. > Please comment on the attached request. The deadline for comments > is April 14, 2009. > > If anyone is aware of the IPR related to the draft, please follow > the procedurs of rfc3979. > > Yakov. > ------- Forwarded Message > > Date: Tue, 31 Mar 2009 10:40:17 -0700 > From: Rex Fernando > To: "'idr@ietf.org'" > Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc > > > The authors would like to request that > draft-marques-idr-best-external-01.txt b e adopted as an IDR WG > document. It was presented in IDR in the Minneapolis IETF. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From kristian@spritelink.net Tue Mar 31 14:59:32 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146FF3A6A6A for ; Tue, 31 Mar 2009 14:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULMU5diHB1aK for ; Tue, 31 Mar 2009 14:59:30 -0700 (PDT) Received: from Ninja.SpriteLink.NET (Ninja.SpriteLink.NET [195.182.5.43]) by core3.amsl.com (Postfix) with ESMTP id 15D2F3A6869 for ; Tue, 31 Mar 2009 14:59:29 -0700 (PDT) Received: from Ninja.SpriteLink.NET (kll@localhost [127.0.0.1]) by Ninja.SpriteLink.NET (8.13.8/8.13.8) with ESMTP id n2VM0BBX082299; Wed, 1 Apr 2009 00:00:11 +0200 (CEST) (envelope-from kristian@spritelink.net) Received: (from kll@localhost) by Ninja.SpriteLink.NET (8.13.8/8.13.8/Submit) id n2VM09Cu082296; Wed, 1 Apr 2009 00:00:09 +0200 (CEST) (envelope-from kristian@spritelink.net) X-Authentication-Warning: Ninja.SpriteLink.NET: kll set sender to kristian@spritelink.net using -f Date: Wed, 1 Apr 2009 00:00:09 +0200 From: Kristian Larsson To: Richard A Steenbergen Message-ID: <20090331220009.GB47012@spritelink.se> References: <49C903E0.4070604@raszuk.net> <20090324185814.GF51443@gerbil.cluepon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090324185814.GF51443@gerbil.cluepon.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 21:59:32 -0000 +1 in favor of the draft. -K On Tue, Mar 24, 2009 at 01:58:14PM -0500, Richard A Steenbergen wrote: > On Tue, Mar 24, 2009 at 09:01:36AM -0700, Robert Raszuk wrote: > > > > * Parsing is an issue on the receiving side. Imagine the case how > > efficient and doable this solution is considering that your ASBR may be > > peering to 4000 up/down-stream peers as pointed out by Vijay. Each of > > those 4000 peers would first need to be able to support such parsing, > > understand to notify it's own administrator or NOC. > > One thing to keep in mind is that for every Google sized network on the > Internet, there are thousands of smaller sized networks with very > different needs. I'm not arguing that it doesn't make sense for Google > to try and design a system which keeps humans off the routers, but for > the vast majority of the world when something goes down there is a human > who logs into a router and does a "show log" to figure out why. In fact, > one could argue that the vast majority of Google's peers operate this > way, therefore Google could still see significant advantages when > sending messages to other networks, even if they don't when receiving > messages from them. > > Plus, this is the kind of thing that could easily be initiated via snmp > or netconf, and picked up via an snmp trap or other monitoring tool > which already exist. > > > * The proposed solution is very difficult deployment wise as both > > peering sides must support the functionality. > > I don't see the difficulty. The best case is that the extra level of > communication helps operators run their networks, the worst case is that > it is unsupported or ignored by the other side because they aren't > expecting it. This is no worse off than we are today. I don't think > anyone is under any delusions that this will ever completely replace out > of band communications, and certainly not from day 1. > > That said, it seems a little odd to argue against standardizing and > implementing a tool which currently doesn't help you because it hasn't > been standardized and implemented. Over time more and more devices will > be able to support it, as networks upgrade their router code. Until > then, it causes no harm, generates no additional work-load, and the > sending party will know if the other side supports the advisory > capability and is even capable of receiving the message. > > > As pointed out yesterday by Keyur Patel or for that matter by Pedro > > Marques when in July 2002 INFORM draft was discussed we are in no > > position to automate all possible actions on the receiver of such > > warning. This is the other side's operator which can in turn make some > > decisions. (Note that for the reload itself there are other proposals > > for example one by Bruno - on how to make it graceful). > > I was actually afraid that this might be the reaction when I saw the > example use of signaling the approach of a max-prefix limit. Clearly a > structured message such as the INFORM draft is a better way to go about > signaling something like this, but I think the point being made is that > an advisory message would at least provide a possible mechanism for > communicating this where today there is none. The ability to send a > free-form message has the advantage of being able to adapt to any > situation that operators might find, instead of requiring the IETF to > think up every possible message type beforehand. > > > * To simplify the solution as well as avoid the must for protocol > > changes to make it working. There is one protocol enhancement I will > > propose instead which could be just an optimization ie solution can work > > without it. > > This feature seems to trivial and easy to implement that I have a hard > time thinking of it as a true protocol change. Think of it as an > extremely simple method of interprovider communication which just > happens to piggyback on the existing BGP protocol for no other reason > than that BGP is the only real interprovider protocol to piggyback on. > > > * To use automated out of band email based notification directly > > targeting corresponding NOC or admin of the peer, but auto generated > > from the router itself > > > > * To optionally allow for auto-receive of the per SAFI remote peer's > > admin/noc email address where the advisory messages should be send to > > > > Coming back to our original diagram: > > > > ___________________________________ > > | | > > ^ v > > NOC_A -> ISP_A @ ASBR_A == EBGP == ASBR_B @ ISP_B -> NOC_B > > One significant advantage to in-band signaling over BGP is the built in > authentication mechanism. By its very nature it is impossible to send to > or receive from someone who is not a directly connected and configured > BGP peer. The existence of the BGP session itself proves both the direct > relationship, and simply and securely associates the message with a > specific peer and BGP session. It also serves to get the message > delivered directly to the people who are most interested in seeing it, > the engineering/operations staff on the other side of the connection who > have access to the router in question. > > To implement this via an out-of-band signaling method, you would need > yet another layer 8 signaling to negotiate NOC contact information and > an authentication mechanism, which must then be kept up to date using > more layer 8 signaling. This is essentially the system of inter-network > communication we use today, it just takes the form of e-mails, telephone > numbers, and the occasional post to operators mailing lists trying to > negotiate a signaling path to someone clueful. You would also need to > deliver the out of band message via some other mechanism such as the > Internet, which one could consider less secure than delivering it via > the existing direct connection between the two routers in question. This > might also require a full table, which is intentionally not configured > on many border routers as an anti-traffic injection mechanism. > > I believe most large networks with a complex management structure > already have existing (plus working and vetted) mechanisms for > collecting data coming in from distributed routers and feeding it back > to centralized monitoring systems, so this would be a natural extension > of that functionality. Adding another out of band communications > infrastructure seems significantly more complex, and significantly less > likely to be implementable in the near future. > > As any network operator who lived through the great BGP MD5 scare is > well aware, communication with third party networks is difficult at > best, and painful or impossible at worst. Consider for example the > process that goes on every time a BGP session flaps. NOC_A receives a > monitoring alert/trap about the session, then tries to determine if this > is an event they were expecting (by checking for layer 8 communication > such as e-mails on the subject), and if they can't find it they then > initiate communication with NOC_B via a mechanism like e-mail or > telephone inquiring about the event. NOC_B then has to determine if this > is an event they were expecting, by searching their own e-mails or > maintenance calendars, or talking to their engineering/ops group. Anyone > who has ever done maintenance on an exchange point router with a few > hundred peers is well aware of the dozens of unnecessary e-mails or > calls this will generate, even if a maintenance notification was sent > out. This also does nothing to address the case of an emergency > maintenance, such as an unscheduled but engineering initiated reload. > > > In unplanned threshold based events the only difference is that this is > > not NOC_A's operator but ASBR_A generating the msg itself. > > > > Examples of planned messages/warnings: > > > > # router reload > > # peer hard clear > > > > Examples of unplanned threshold based messages: > > > > # prefix-limit reaching X% > > # dampening applied or about to be applied on prefix Z > > etc... > > I agree that structured messages certainly have their place, and I agree > that prefix-limit reaching/exceeded/etc is certainly best served by that > type of message, but I don't think this replaces the benefits of a > free-form text message. There are already notification messages for a > peer hard clear, but they aren't capable of telling the other side WHY > the session was cleared. > > This issue reaches beyond the world of protocol design, and plants > itself firmly in the realm of the network operator community. Certainly > every network operator I've talked to has all but jumped for joy at the > prospect of having this functionality, and I'm certain we can find a few > of them to state as much on this list. The only thing the IETF needs to > do is provide the communication mechanism (which is fortunately > extremely simple to do), and then leave the network operators to use the > tool as they see fit. > > -- > Richard A Steenbergen http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From asr@latency.net Tue Mar 31 15:14:33 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF543A6AEB for ; Tue, 31 Mar 2009 15:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPT+IhLSjhB2 for ; Tue, 31 Mar 2009 15:14:32 -0700 (PDT) Received: from og.latency.net (og.latency.net [64.21.79.2]) by core3.amsl.com (Postfix) with ESMTP id 578EC3A6AD8 for ; Tue, 31 Mar 2009 15:14:32 -0700 (PDT) Received: by og.latency.net (Postfix, from userid 1000) id A558313FB2E; Tue, 31 Mar 2009 18:15:31 -0400 (EDT) Date: Tue, 31 Mar 2009 18:15:31 -0400 From: Adam Rothschild To: idr@ietf.org Message-ID: <20090331221531.GI76021@latency.net> References: <49C903E0.4070604@raszuk.net> <20090324185814.GF51443@gerbil.cluepon.net> <20090331220009.GB47012@spritelink.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090331220009.GB47012@spritelink.se> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Subject: Re: [Idr] draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 22:14:33 -0000 +1 here. We're sufficiently deep in commentary on this thread; usual pedantry aside, I've yet to see a clear explanation of what Bad Things would happen if we were to move forward with Mr. Scholl's proposal. As a network heavily invested in exchange peering, out-of-band communication is all well and good on paper, but in practice, often easier said than done when attempting to interface with a wide variety of remote networks (of varying competence, staffing/coverage, language comprehension, ...) in real time. Tom's implementation augments the protocol with a much-needed last resort. -a