From jhaas@slice.pfrc.org Tue Feb 4 12:52:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BEA1A010F for ; Tue, 4 Feb 2014 12:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OglN6fZ0ggAj for ; Tue, 4 Feb 2014 12:52:54 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1EA1A00EC for ; Tue, 4 Feb 2014 12:52:54 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E6873C25F; Tue, 4 Feb 2014 15:52:53 -0500 (EST) Date: Tue, 4 Feb 2014 15:52:53 -0500 From: Jeffrey Haas To: Susan Hares Message-ID: <20140204205253.GA32232@pfrc> References: <005501cf1e9b$89bfdb50$9d3f91f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005501cf1e9b$89bfdb50$9d3f91f0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr wg , draft-rekhter-mdcs@tools.ietf.org, "'John G. Scudder'" Subject: Re: [Idr] Request WG adoption for draft-rekhter-mdrs and draft-rekhter-mdcs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 20:52:56 -0000 On Fri, Jan 31, 2014 at 10:45:58AM -0500, Susan Hares wrote: > IDR: > The following drafts have been accepted by the WG (due to October WG all) > > https://datatracker.ietf.org/doc/draft-rekhter-mdcs/ > https://datatracker.ietf.org/doc/draft-rekhter-mdrs/ > > Please submit these as: > > Draft-ietf-idr-mdcs-00 > Draft-ietf-idr-mdrs-00 > > Thank you to Jeff Haas for reminding me that this WG Adoption call had not > been posted. Thanks, Sue. The posting has been done and is in IDR chair queue for approval. -- Jeff From internet-drafts@ietf.org Tue Feb 4 14:40:02 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AFF1A0169; Tue, 4 Feb 2014 14:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP7nRIJG4HyM; Tue, 4 Feb 2014 14:40:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8321A0127; Tue, 4 Feb 2014 14:40:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204224000.8464.72726.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 14:40:00 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-mdrs-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 22:40:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Multicast Distribution Reachability Signaling Authors : Huajin Jeng Jeffrey Haas Yakov Rekhter Jeffrey (Zhaohui) Zhang Filename : draft-ietf-idr-mdrs-00.txt Pages : 6 Date : 2014-02-04 Abstract: This document describes a mechanism whereby a subscriber's Internet service provider may signal in BGP the ability of the subscriber network to receive content using multicast connectivity. This mechanism is called Multicast Distribution Reachability Signaling (MDRS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-mdrs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-mdrs-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Wed Feb 5 03:27:43 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46791A00E5 for ; Wed, 5 Feb 2014 03:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.953 X-Spam-Level: X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jEY8fE-vjEd for ; Wed, 5 Feb 2014 03:27:42 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 58A621A00DE for ; Wed, 5 Feb 2014 03:27:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A39EE7FC393; Wed, 5 Feb 2014 03:27:40 -0800 (PST) To: jgs@juniper.net, rchandra@sonoasystems.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20140205112740.A39EE7FC393@rfc-editor.org> Date: Wed, 5 Feb 2014 03:27:40 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Technical Errata Reported] RFC5492 (3882) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 11:27:44 -0000 The following errata report has been submitted for RFC5492, "Capabilities Advertisement with BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5492&eid=3882 -------------------------------------- Type: Technical Reported by: Ramakrishna DTV Section: 3 Original Text ------------- " A BGP speaker determines that its peer doesn't support capabilities advertisement if, in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. (This is a consequence of the base BGP-4 specification [RFC4271] and not a new requirement.) In this case, the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter." Corrected Text -------------- " A BGP speaker determines that its peer doesn't support capabilities advertisement if, in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. (This is a consequence of the base BGP-4 specification [RFC4271] and not a new requirement.) The next actions depends on the BGP speaker that received the NOTIFICATION. The speaker may intend to re-establish a BGP connection with the peer. In this case, the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter. On the other hand, the speaker may not intend to re-establish peering. For example, a BGP speaker may not intend to re-establish peering if it established peering to exchange IPv6 routes and determines that its peer does not support capabilities advertisement. The decision to re-establish the peering is local to the speaker." Notes ----- Notes: As explained above, it does not always make sense to re-establish peering when the peer does not support capabilities advertisement. Indeed, in a very similar scenario, this RFC itself suggests the proposed behavior. Consider the following text in Section 3: " If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker MAY send a NOTIFICATION message to the peer and terminate peering (see Section "Extensions to Error Handling" for more details). For example, a BGP speaker may need to terminate peering if it established peering to exchange IPv6 routes and determines that its peer does not support Multiprotocol Extensions for BGP-4 [RFC4760]. The Error Subcode in the NOTIFICATION message is then set to Unsupported Capability. The message MUST contain the capability or capabilities that cause the speaker to send the message. The decision to send the message and terminate the peering is local to the speaker. If terminated, such peering SHOULD NOT be re-established automatically." Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5492 (draft-ietf-idr-rfc3392bis-05) -------------------------------------- Title : Capabilities Advertisement with BGP-4 Publication Date : February 2009 Author(s) : J. Scudder, R. Chandra Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Wed Feb 5 09:08:12 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5270F1A00E2; Wed, 5 Feb 2014 09:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoPtq1hc46R0; Wed, 5 Feb 2014 09:08:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A40531A0013; Wed, 5 Feb 2014 09:08:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140205170810.26696.48352.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2014 09:08:10 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-mdcs-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 17:08:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Multicast Distribution Control Signaling Authors : Huajin Jeng Jeffrey Haas Yakov Rekhter Jeffrey (Zhaohui) Zhang Filename : draft-ietf-idr-mdcs-00.txt Pages : 9 Date : 2014-02-04 Abstract: This document describes a mechanism whereby the BGP Flow Specification NLRI format may be utilized to distribute multicast Control Plane filters. This mechanism is called Multicast Distribution Control Signaling (MDCS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-mdcs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-mdcs-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jhaas@slice.pfrc.org Wed Feb 5 15:05:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95181A0281 for ; Wed, 5 Feb 2014 15:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGB3AOw_qbtf for ; Wed, 5 Feb 2014 15:05:30 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 831DA1A0224 for ; Wed, 5 Feb 2014 15:05:30 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id B50C7C147; Wed, 5 Feb 2014 18:05:29 -0500 (EST) Date: Wed, 5 Feb 2014 18:05:29 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20140205230529.GD20613@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-idr-flowspec-redirect-rt-bis-01.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:05:33 -0000 Working Group, I've updated the flowspec redirect clarification I-D that I presented on during last IETF. The goal was to accommodate for the re-work of the Extended Community registries that Eric Rosen and Yakov Rekhter have done. That document is currently in the RFC Editor queue. As presented at the last IETF, I'd like to request Working Group adoption for this draft. Once the dependent draft has cleared the RFC editor's queue, I'd recommend doing a WGLC on this document. This draft 'tis janitorial work. :-) -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- Date: Wed, 05 Feb 2014 15:01:25 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-haas-idr-flowspec-redirect-rt-bis-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Clarification of the Flowspec Redirect Extended Community Author : Jeffrey Haas Filename : draft-haas-idr-flowspec-redirect-rt-bis-01.txt Pages : 6 Date : 2014-02-05 Abstract: This document clarifies the formatting of the the BGP Flowspec Redirect Extended Community, originally documented in RFC 5575. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-idr-flowspec-redirect-rt-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haas-idr-flowspec-redirect-rt-bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-haas-idr-flowspec-redirect-rt-bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- From internet-drafts@ietf.org Wed Feb 5 17:52:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7271A0226; Wed, 5 Feb 2014 17:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shOqLt9BWMQu; Wed, 5 Feb 2014 17:52:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C4C1A0194; Wed, 5 Feb 2014 17:52:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206015214.27070.71277.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2014 17:52:14 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-enhanced-gr-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 01:52:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Accelerated Routing Convergence for BGP Graceful Restart Authors : Keyur Patel Enke Chen Rex Fernando John Scudder Filename : draft-ietf-idr-enhanced-gr-04.txt Pages : 9 Date : 2014-02-05 Abstract: In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-enhanced-gr/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-enhanced-gr-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-enhanced-gr-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Feb 5 17:59:03 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A9F1A0137; Wed, 5 Feb 2014 17:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjw4xmgw4qwq; Wed, 5 Feb 2014 17:59:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6821A0228; Wed, 5 Feb 2014 17:58:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206015858.27126.23508.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2014 17:58:58 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 01:59:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Revised Error Handling for BGP UPDATE Messages Authors : John G. Scudder Enke Chen Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-05.txt Pages : 12 Date : 2014-02-05 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Feb 5 21:38:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3345D1A0372; Wed, 5 Feb 2014 21:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p59yshojQHXP; Wed, 5 Feb 2014 21:38:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EC61A02B2; Wed, 5 Feb 2014 21:38:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206053832.6068.85900.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2014 21:38:32 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 05:38:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Enhanced Route Refresh Capability for BGP-4 Authors : Keyur Patel Enke Chen Balaji Venkatachalapathy Filename : draft-ietf-idr-bgp-enhanced-route-refresh-06.txt Pages : 7 Date : 2014-02-05 Abstract: In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP RIB inconsistencies in a non-disruptive manner. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-enhanced-route-refresh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-enhanced-route-refresh-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-enhanced-route-refresh-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shares@ndzh.com Thu Feb 6 06:47:50 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F731A013D for ; Thu, 6 Feb 2014 06:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.444 X-Spam-Level: * X-Spam-Status: No, score=1.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RANDOM_SURE=0.499] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUHr2c5iGjBD for ; Thu, 6 Feb 2014 06:47:48 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A81E21A012E for ; Thu, 6 Feb 2014 06:47:48 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jon Mitchell'" References: <009601cf109b$ffc83580$ff58a080$@ndzh.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4700D@eusaamb109.ericsson.se> <2F3EBB88EC3A454AAB08915FBF0B8C7E02F4727D@eusaamb109.ericsson.se> <012e01cf10cc$1b1186e0$513494a0$@ndzh.com> <20140114133707.GA4554@puck.nether.net> <009001cf116a$0a021d30$1e065790$@ndzh.com> In-Reply-To: <009001cf116a$0a021d30$1e065790$@ndzh.com> Date: Thu, 6 Feb 2014 09:47:38 -0500 Message-ID: <015601cf234a$61a74d20$24f5e760$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFUHLgnFdayqrX0fhkJ34lvgHCiUAGT+LeVAMt3AtgB724Y3wHkkHVcAQBy8nICqD8ruptPegSQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' , Jon.Mitchell@microsoft.com, "'John G. Scudder'" Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 14:47:50 -0000 Idr Draft-ietf-idr-last-as-reservation-01 document has passed WG LC, and will be forwarded to the Routing AD. Thank you, Sue Hares IDR co-chair -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, January 14, 2014 3:49 PM To: 'Jon Mitchell' Cc: 'idr wg'; 'John G. Scudder'; Jon.Mitchell@microsoft.com Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 Jon: Unless we hear otherwise, we'll leave it at informational. I'm still awaiting Stewart Bryant's response as the responsible AD. Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jon Mitchell Sent: Tuesday, January 14, 2014 8:37 AM To: Susan Hares Cc: Jon.Mitchell@microsoft.com; 'John G. Scudder'; 'idr wg' Subject: Re: [Idr] WG LC for draft-ietf-idr-last-as-reservation-01 On 13/01/14 20:58 -0500, Susan Hares wrote: > Jakob: > > Yes, I agree 100% Jakob. Standard assignment of AS numbers can be > approached either way. > > Standards: > Look, we are assigning these AS numbers. If you want to play in the > Internet > - pay attention (standard) because standard implementation will use it. > > Informational: > What 2 bgp peers do in the privacy of their own private ASes, is the > business of the two AS administrations. For the DC BGP, this can > still work. > > So... arguments can balance either way. To throw another option on the table - BCP (6 specifically), which is where RFC 6996 ended up. This is a primarily a reservation of space draft with a recommendation to operators on (non-)use of that space. -Jon _______________________________________________ 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 internet-drafts@ietf.org Thu Feb 6 06:51:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1381A0184; Thu, 6 Feb 2014 06:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry5vjqmvd6F4; Thu, 6 Feb 2014 06:51:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 926041A013C; Thu, 6 Feb 2014 06:51:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206145116.24043.8022.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2014 06:51:16 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 14:51:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Reservation of Last Autonomous System (AS) Numbers Authors : Jeffrey Haas Jon Mitchell Filename : draft-ietf-idr-last-as-reservation-02.txt Pages : 4 Date : 2014-02-06 Abstract: This document reserves two Autonomous System numbers (ASNs) at the end of the 16 bit and 32 bit ranges, described in this document as "Last ASNs" and provides guidance to implementers and operators on their use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-last-as-reservation-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jhaas@slice.pfrc.org Thu Feb 6 07:25:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3245F1A0143 for ; Thu, 6 Feb 2014 07:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7_Nm4_fR6sy for ; Thu, 6 Feb 2014 07:25:57 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id ECF7B1A03EE for ; Thu, 6 Feb 2014 07:25:56 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id D303AC2C3; Thu, 6 Feb 2014 10:25:55 -0500 (EST) Date: Thu, 6 Feb 2014 10:25:55 -0500 From: Jeffrey Haas To: Susan Hares Message-ID: <20140206152555.GC23551@pfrc> References: <007701cf1de8$53571d70$fa055850$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007701cf1de8$53571d70$fa055850$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "'Keyur Patel \(keyupate\)'" , idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 15:25:59 -0000 On Thu, Jan 30, 2014 at 01:23:07PM -0500, Susan Hares wrote: > IDR WG: > > We will have a 1 week WG LC on this version of the > draft-ietf-idr-bgp-enhanced-route-refresh-06.txt > > Please comment. It would help if you would indicate: support/no-support in > your discussion. I continue to support the draft. I think the clarifications for covering end-of-rib procedures (regardless of whether GR is being used or not) are valuable. Personally, I think it'd be wise to not process the enhanced RR procedures until GR is complete but I think that can be an implementation decision. (The justification is that there's a *lot* of work going on while processing GR and it's more valuable to get RIBs in some initial state of synchronization rather than worry about trying to fill in holes that might be present in the midst of it.) -- Jeff From shares@ndzh.com Thu Feb 6 07:39:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549AE1A01E8 for ; Thu, 6 Feb 2014 07:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoGhfza3m9m1 for ; Thu, 6 Feb 2014 07:39:39 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 455B01A018E for ; Thu, 6 Feb 2014 07:39:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jeffrey Haas'" References: <007701cf1de8$53571d70$fa055850$@ndzh.com> <20140206152555.GC23551@pfrc> In-Reply-To: <20140206152555.GC23551@pfrc> Date: Thu, 6 Feb 2014 10:39:27 -0500 Message-ID: <001201cf2351$9f3dbbe0$ddb933a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGxPj1Dal1f7T6ogADUl2weXy9pgLjVe5ZAOjZ9xGaGrd/4A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "'Keyur Patel \(keyupate\)'" , idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 15:39:40 -0000 Jeff: Please provide more details on your opinion on this information to the list: "Personally, I think it'd be wise to not process the enhanced RR procedures until GR is complete but I think that can be an implementation decision." (The justification is that there's a *lot* of work going on while processing GR and it's more valuable to get RIBs in some initial state of synchronization rather than worry about trying to fill in holes that might be present in the midst of it.) Sue Hares -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Thursday, February 06, 2014 10:26 AM To: Susan Hares Cc: 'Keyur Patel (keyupate)'; idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt On Thu, Jan 30, 2014 at 01:23:07PM -0500, Susan Hares wrote: > IDR WG: > > We will have a 1 week WG LC on this version of the > draft-ietf-idr-bgp-enhanced-route-refresh-06.txt > > Please comment. It would help if you would indicate: > support/no-support in your discussion. I continue to support the draft. I think the clarifications for covering end-of-rib procedures (regardless of whether GR is being used or not) are valuable. Personally, I think it'd be wise to not process the enhanced RR procedures until GR is complete but I think that can be an implementation decision. (The justification is that there's a *lot* of work going on while processing GR and it's more valuable to get RIBs in some initial state of synchronization rather than worry about trying to fill in holes that might be present in the midst of it.) -- Jeff From jhaas@slice.pfrc.org Thu Feb 6 08:10:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EA91A03DB for ; Thu, 6 Feb 2014 08:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4Fgj2nGbgxn for ; Thu, 6 Feb 2014 08:10:55 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5387F1A0193 for ; Thu, 6 Feb 2014 08:10:55 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4A787C2C3; Thu, 6 Feb 2014 11:10:54 -0500 (EST) Date: Thu, 6 Feb 2014 11:10:54 -0500 From: Jeffrey Haas To: Susan Hares Message-ID: <20140206161054.GE23551@pfrc> References: <007701cf1de8$53571d70$fa055850$@ndzh.com> <20140206152555.GC23551@pfrc> <001201cf2351$9f3dbbe0$ddb933a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201cf2351$9f3dbbe0$ddb933a0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "'Keyur Patel \(keyupate\)'" , idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 16:10:56 -0000 On Thu, Feb 06, 2014 at 10:39:27AM -0500, Susan Hares wrote: > Jeff: > > Please provide more details on your opinion on this information to the list: Sure. :-) > "Personally, I think it'd be wise to not process the enhanced RR procedures > until GR is complete but I think that can be an implementation decision." > (The justification is that there's a *lot* of work going on while processing > GR and it's more valuable to get RIBs in some initial state of > synchronization rather than worry about trying to fill in holes that might > be present in the midst of it.) When a router that is assisting with a graceful restart, it has to do several expensive things: - Mark all routes received from that peer stale. - Receive all routes again from that peer. - Upon EoR (per family), sweep all stale routes not otherwise refreshed. In a non-multisession peering environment, you have one TCP socket between you and the restarting peer. Presuming more than one AFI/SAFI negotiated (lets say IPv4 unicast and L3VPN), even if you've finished refreshing IPv4 unicast and could service a enhanced route refresh for that family, you're still doing a lot of work trying to shove routes down the socket for L3VPN. Even if you presume you ignore CPU or route-queueing efficiencies for an implementation (let's say that some IPv4 Unicast is queued ahead of other stuff), to service the refresh for those important routes you'd still push off initial convergence of L3VPN. Whether this is wise is clearly an implementation choice. Implementations are free to interleave queued routes as they wish and there are competing motivations as to why they'd want to servicing things in a given way. But in abstract, delaying initial convergence seems unwise. An implementation would be free to queue the work requested for a enhanced route refresh and not interrupt GR resync. That requires no changes to the spec. The spec could offer the opinion that you probably should do this, rather than allowing a refresh to interrupt GR procedures (which impact timers) by reinserting routes that have been sent at least once into the queue. But that gets pretty deep into implementation. Trying to be normative here (RFC 2119 language) seems unwise since it simply puts an implementor into a pedantic vice useful only to make test tool vendors happy. -- Jeff From keyupate@cisco.com Thu Feb 6 09:51:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6D71A03EA for ; Thu, 6 Feb 2014 09:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChIFElseklKV for ; Thu, 6 Feb 2014 09:51:13 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2C19A1A013C for ; Thu, 6 Feb 2014 09:51:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3388; q=dns/txt; s=iport; t=1391709073; x=1392918673; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MaZp4vqb1U14gfT0JwSzID4/fTilaAnacvfnlbJz+Cs=; b=AY50iqS++7vVUb1C7V6rK5fR4iRmaXxNL+8Z1e4gcYp4J6B1e5mh8oGm ZFw7BoUP9uS5P6FgKEgPlvFb89qr/f4Hpv5Q4wd/MLPjVQ12pW2UDXalW yhXMBH34OjKDF864nLElw1Y06j/mTZtrjaGgrEcbzfs0SVj7RjSPVU54i 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAGrK81KtJV2b/2dsb2JhbABZgw44Vb1MgQ0WAXSDfQEBAQQBAQE3NAsSAQgOCh43CyUCBAENBYgEDcZFEwSPEgeENgSUM4NjkhSDK4Iq X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="299335301" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 06 Feb 2014 17:51:12 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s16HpBS8026707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 17:51:11 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.117]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 11:51:11 -0600 From: "Keyur Patel (keyupate)" To: Jeffrey Haas , Susan Hares Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt Thread-Index: AQHPI2QEDal1f7T6ogADUl2weXy9pg== Date: Thu, 6 Feb 2014 17:51:10 +0000 Message-ID: In-Reply-To: <20140206161054.GE23551@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C473FB20B8B4E43A453FACBD45E6966@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 17:51:16 -0000 Hi Jeff, As part of rev 6, we added the following to Section 4: The following procedures are specified in order to simplify the interaction with the BGP Graceful Restart [RFC4724]. For a BGP speaker that supports the BGP Graceful Restart, it MUST NOT send a BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the AFI/SAFI to the neighbor. A BGP speaker that has received the Graceful Restart Capability from its neighbor, MUST ignore any BoRRs for an AFI/SAFI from the neighbor before the speaker receives the EoR for the given AFI/SAFI from the neighbor. The BGP speaker SHOULD log an error of the condition for further analysis. Regards, Keyur On 2/6/14 8:10 AM, "Jeffrey Haas" wrote: >On Thu, Feb 06, 2014 at 10:39:27AM -0500, Susan Hares wrote: >> Jeff:=20 >>=20 >> Please provide more details on your opinion on this information to the >>list: > >Sure. :-) > >> "Personally, I think it'd be wise to not process the enhanced RR >>procedures >> until GR is complete but I think that can be an implementation >>decision." >> (The justification is that there's a *lot* of work going on while >>processing >> GR and it's more valuable to get RIBs in some initial state of >> synchronization rather than worry about trying to fill in holes that >>might >> be present in the midst of it.) > >When a router that is assisting with a graceful restart, it has to do >several expensive things: >- Mark all routes received from that peer stale. >- Receive all routes again from that peer. >- Upon EoR (per family), sweep all stale routes not otherwise refreshed. > >In a non-multisession peering environment, you have one TCP socket between >you and the restarting peer. Presuming more than one AFI/SAFI negotiated >(lets say IPv4 unicast and L3VPN), even if you've finished refreshing IPv4 >unicast and could service a enhanced route refresh for that family, you're >still doing a lot of work trying to shove routes down the socket for >L3VPN. > >Even if you presume you ignore CPU or route-queueing efficiencies for an >implementation (let's say that some IPv4 Unicast is queued ahead of other >stuff), to service the refresh for those important routes you'd still push >off initial convergence of L3VPN. Whether this is wise is clearly an >implementation choice. > >Implementations are free to interleave queued routes as they wish and >there >are competing motivations as to why they'd want to servicing things in a >given way. But in abstract, delaying initial convergence seems unwise. > >An implementation would be free to queue the work requested for a enhanced >route refresh and not interrupt GR resync. That requires no changes to >the >spec. > >The spec could offer the opinion that you probably should do this, rather >than allowing a refresh to interrupt GR procedures (which impact timers) >by >reinserting routes that have been sent at least once into the queue. But >that gets pretty deep into implementation. Trying to be normative here >(RFC >2119 language) seems unwise since it simply puts an implementor into a >pedantic vice useful only to make test tool vendors happy. > >-- Jeff >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From jakob.heitz@ericsson.com Thu Feb 6 10:06:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5451A0213 for ; Thu, 6 Feb 2014 10:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9MATG51euJu for ; Thu, 6 Feb 2014 10:06:20 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFED1A01EA for ; Thu, 6 Feb 2014 10:06:20 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-02-52f3cf1777c9 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 03.20.12743.71FC3F25; Thu, 6 Feb 2014 19:06:16 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0387.000; Thu, 6 Feb 2014 13:06:18 -0500 From: Jakob Heitz To: "Keyur Patel (keyupate)" , Jeffrey Haas , Susan Hares Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt Thread-Index: AQHPHefuyl4e2PkcMUKSCY4dU5/By5qd6KaAgArO0ICAAAPIgIAACMkAgAAcBAD//7BfkA== Date: Thu, 6 Feb 2014 18:06:18 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02F7D1BD@eusaamb109.ericsson.se> References: <20140206161054.GE23551@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXSPt67E+c9BBm+OCVi8uv2MyWL/wbes Fo1bz7NZ/HnzisWBxWPK742sHkuW/GTymP36OqvH5d6trAEsUVw2Kak5mWWpRfp2CVwZK7q/ sxVMlatYs+YeawPjaYkuRk4OCQETieO3e1kgbDGJC/fWs3UxcnEICRxhlLh0azcrhLOMUWLX y2WMIFVsAjoS3653MYPYIgKFEj9etLKC2MwCihIX/3YwgdjCAs4Su/7/ZYWocZH4e7+fEcIO kzi1dy9YL4uAikR/63+wel4BX4kL3e/A6oWA7Plz14LVcAoYSHQ/eQpmMwJd9/3UGiaIXeIS t57MZ4K4WkBiyZ7zzBC2qMTLx/9YIWwliUlLz0HdpiOxYPcnNghbW2LZwtfMEHsFJU7OfMIy gVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UYGmxiB8XRMgk13B+Oel5aHGKU5WJTEeb+8 dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLjbp+q+43HJLTMD8zz/Lxf99F3o2D+vXxrh ZX55KxOKFz9lKGRbzGux7RLv6QT5R4FrV86t/Z/+MHPqvpX1s312rt3TfNFuUucE/enB257U KrtMeLZm4dbyg/YMew7NNbjWtPjE/7Q0o/nrw14u7T/Q1c4Y723+SEJ/CmtJkHD79Y8a2uky P3YosRRnJBpqMRcVJwIADuk+THUCAAA= Cc: "idr@ietf.org" Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 18:06:22 -0000 support -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Keyur Patel (keyupate) Sent: Thursday, February 06, 2014 9:51 AM To: Jeffrey Haas; Susan Hares Cc: idr@ietf.org Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt Hi Jeff, As part of rev 6, we added the following to Section 4: The following procedures are specified in order to simplify the interaction with the BGP Graceful Restart [RFC4724]. For a BGP speaker that supports the BGP Graceful Restart, it MUST NOT send a BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the AFI/SAFI to the neighbor. A BGP speaker that has received the Graceful Restart Capability from its neighbor, MUST ignore any BoRRs for an AFI/SAFI from the neighbor before the speaker receives the EoR for the given AFI/SAFI from the neighbor. The BGP speaker SHOULD log an error of the condition for further analysis. Regards, Keyur On 2/6/14 8:10 AM, "Jeffrey Haas" wrote: >On Thu, Feb 06, 2014 at 10:39:27AM -0500, Susan Hares wrote: >> Jeff:=20 >>=20 >> Please provide more details on your opinion on this information to=20 >>the >>list: > >Sure. :-) > >> "Personally, I think it'd be wise to not process the enhanced RR=20 >>procedures until GR is complete but I think that can be an=20 >>implementation decision." >> (The justification is that there's a *lot* of work going on while=20 >>processing GR and it's more valuable to get RIBs in some initial=20 >>state of synchronization rather than worry about trying to fill in=20 >>holes that might be present in the midst of it.) > >When a router that is assisting with a graceful restart, it has to do=20 >several expensive things: >- Mark all routes received from that peer stale. >- Receive all routes again from that peer. >- Upon EoR (per family), sweep all stale routes not otherwise refreshed. > >In a non-multisession peering environment, you have one TCP socket=20 >between you and the restarting peer. Presuming more than one AFI/SAFI=20 >negotiated (lets say IPv4 unicast and L3VPN), even if you've finished=20 >refreshing IPv4 unicast and could service a enhanced route refresh for=20 >that family, you're still doing a lot of work trying to shove routes=20 >down the socket for L3VPN. > >Even if you presume you ignore CPU or route-queueing efficiencies for=20 >an implementation (let's say that some IPv4 Unicast is queued ahead of=20 >other stuff), to service the refresh for those important routes you'd=20 >still push off initial convergence of L3VPN. Whether this is wise is=20 >clearly an implementation choice. > >Implementations are free to interleave queued routes as they wish and=20 >there are competing motivations as to why they'd want to servicing=20 >things in a given way. But in abstract, delaying initial convergence=20 >seems unwise. > >An implementation would be free to queue the work requested for a=20 >enhanced route refresh and not interrupt GR resync. That requires no=20 >changes to the spec. > >The spec could offer the opinion that you probably should do this,=20 >rather than allowing a refresh to interrupt GR procedures (which impact=20 >timers) by reinserting routes that have been sent at least once into=20 >the queue. But that gets pretty deep into implementation. Trying to=20 >be normative here (RFC >2119 language) seems unwise since it simply puts an implementor into a=20 >pedantic vice useful only to make test tool vendors happy. > >-- Jeff >_______________________________________________ >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 jhaas@slice.pfrc.org Thu Feb 6 12:12:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235351A0461 for ; Thu, 6 Feb 2014 12:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOd6P1IPX2jy for ; Thu, 6 Feb 2014 12:12:56 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E36221A0425 for ; Thu, 6 Feb 2014 12:12:55 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id AEFFAC2C3; Thu, 6 Feb 2014 15:12:54 -0500 (EST) Date: Thu, 6 Feb 2014 15:12:54 -0500 From: Jeffrey Haas To: "Keyur Patel (keyupate)" Message-ID: <20140206201254.GG23551@pfrc> References: <20140206161054.GE23551@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 20:12:57 -0000 Keyur, On Thu, Feb 06, 2014 at 05:51:10PM +0000, Keyur Patel (keyupate) wrote: > As part of rev 6, we added the following to Section 4: It was this text that brought the case to mind. > > The following procedures are specified in order to simplify the > interaction with the BGP Graceful Restart [RFC4724]. For a BGP > speaker that supports the BGP Graceful Restart, it MUST NOT send a > BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the > AFI/SAFI to the neighbor. A BGP speaker that has received the > Graceful Restart Capability from its neighbor, MUST ignore any BoRRs > for an AFI/SAFI from the neighbor before the speaker receives the EoR > for the given AFI/SAFI from the neighbor. The BGP speaker SHOULD log > an error of the condition for further analysis. > > The distinction is that I think we shouldn't ask for enhanced RRs (or process them if restarting) until restart procedures are concluded. The above text makes it ok to request one for a given afi/safi once that afi/safi has sent eor. -- Jeff From keyupate@cisco.com Thu Feb 6 12:23:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622EF1A04C1 for ; Thu, 6 Feb 2014 12:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-NqjAp5JfZv for ; Thu, 6 Feb 2014 12:23:52 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1841A1A04C4 for ; Thu, 6 Feb 2014 12:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1379; q=dns/txt; s=iport; t=1391718231; x=1392927831; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vkreqrkUN14zNhQLFhD9868S3EYWa8LSaHH+2xH6c9w=; b=DIbgv7WrHlxKvpi9ZTRYjFRNeuIJO135qCin2pZxprumnEl74SOj9o6O ypArMsz7z4pGUxHSnBxPxaTP/CMLwxBIjSCkbmDohW1QdH5D49ellWXNv A+qcS/+745pOu+ntX+1uMqMcidoqwyRqr0K+MomvpYNR3Ca0ukRfMyPvs o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGvu81KtJV2Z/2dsb2JhbABZgwyBD75zgQ0WdIIlAQEBBDo/EgEIDgoeQiUCBA4FiAXNKBeOegeEOAEDlEKDaZIhgy2CKg X-IronPort-AV: E=Sophos;i="4.95,795,1384300800"; d="scan'208";a="302379047" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 06 Feb 2014 20:23:50 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s16KNokg005695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 20:23:51 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.117]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 14:23:50 -0600 From: "Keyur Patel (keyupate)" To: Jeffrey Haas Thread-Topic: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt Thread-Index: AQHPI3lYDal1f7T6ogADUl2weXy9pg== Date: Thu, 6 Feb 2014 20:23:49 +0000 Message-ID: In-Reply-To: <20140206201254.GG23551@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.63] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 20:23:55 -0000 On 2/6/14 12:12 PM, "Jeffrey Haas" wrote: >Keyur, > >On Thu, Feb 06, 2014 at 05:51:10PM +0000, Keyur Patel (keyupate) wrote: >> As part of rev 6, we added the following to Section 4: > >It was this text that brought the case to mind. > >> >> The following procedures are specified in order to simplify the >> interaction with the BGP Graceful Restart [RFC4724]. For a BGP >> speaker that supports the BGP Graceful Restart, it MUST NOT send a >> BoRR for an AFI/SAFI to a neighbor before it sends the EOR for the >> AFI/SAFI to the neighbor. A BGP speaker that has received the >> Graceful Restart Capability from its neighbor, MUST ignore any BoRRs >> for an AFI/SAFI from the neighbor before the speaker receives the EoR >> for the given AFI/SAFI from the neighbor. The BGP speaker SHOULD log >> an error of the condition for further analysis. >>=20 >> > >The distinction is that I think we shouldn't ask for enhanced RRs (or >process them if restarting) until restart procedures are concluded. The >above text makes it ok to request one for a given afi/safi once that >afi/safi has sent eor. Right. I don't know if we can control the "ask". But the text above ensures (like you said) that the refresh reply will be delayed till EOR is serviced. Regards, Keyur =20 > >-- Jeff From jhaas@slice.pfrc.org Thu Feb 6 12:31:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CBB1A046E for ; Thu, 6 Feb 2014 12:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzCVoCoE-Y-V for ; Thu, 6 Feb 2014 12:31:03 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C09A41A04DC for ; Thu, 6 Feb 2014 12:31:03 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id AE53BC333; Thu, 6 Feb 2014 15:31:02 -0500 (EST) Date: Thu, 6 Feb 2014 15:31:02 -0500 From: Jeffrey Haas To: "Keyur Patel (keyupate)" Message-ID: <20140206203102.GH23551@pfrc> References: <20140206201254.GG23551@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "idr@ietf.org" , Susan Hares Subject: Re: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 20:31:06 -0000 On Thu, Feb 06, 2014 at 08:23:49PM +0000, Keyur Patel (keyupate) wrote: > >The distinction is that I think we shouldn't ask for enhanced RRs (or > >process them if restarting) until restart procedures are concluded. The > >above text makes it ok to request one for a given afi/safi once that > >afi/safi has sent eor. > > Right. I don't know if we can control the "ask". But the text above > ensures (like you said) that the refresh reply will be delayed till EOR is > serviced. Just to close this loop for Sue, as I said in my original reply, the existing text is sufficient. If we were going to add text, it'd basically say "do not process received refresh requests until GR procedures are complete". I'm not going to press heavily for such a thing in the spec. But it's likely what I'd suggest we put in our implementation. -- Jeff From juancamilo.cardona@imdea.org Fri Feb 7 08:30:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E611A03F5 for ; Fri, 7 Feb 2014 08:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkQXW8xPNm3R for ; Fri, 7 Feb 2014 08:30:14 -0800 (PST) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3F01A03D6 for ; Fri, 7 Feb 2014 08:30:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id CEBAF1B7005; Fri, 7 Feb 2014 17:29:50 +0100 (CET) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s99SJVRsFu47; Fri, 7 Feb 2014 17:29:45 +0100 (CET) Received: from GTGNG4J (unknown [193.145.14.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juancamilo.cardona) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id 5365A1B7004; Fri, 7 Feb 2014 17:29:44 +0100 (CET) From: "Juan Camilo Cardona" To: Date: Fri, 7 Feb 2014 17:30:18 +0100 Message-ID: <00d001cf2421$e3a696a0$aaf3c3e0$@cardona@imdea.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8kFu9RfsuNJfBAT0exhITDbFvXEgABTl+A Content-Language: es Cc: 'Jeffrey Haas' Subject: [Idr] FW: New Version Notification for draft-francois-idr-addpath-limit-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:30:16 -0000 Hello everyone, We just posted a draft proposing the creation of a mechanism between = ADD-PATH devices that allows the receiving side to communicate a limit = on the maximum number of paths it wants to receive. We are looking = forward to your comments. Best regards, Camilo Cardona -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: viernes, 07 de febrero de 2014 16:12 To: Jeffrey Haas; Jeffrey Haas; Pierre Francois; Adam Simpson; Camilo = Cardona; Adam Simpson; Camilo Cardona; Pierre Francois Subject: New Version Notification for = draft-francois-idr-addpath-limit-00.txt A new version of I-D, draft-francois-idr-addpath-limit-00.txt has been successfully submitted by Camilo Cardona and posted to the IETF = repository. Name: draft-francois-idr-addpath-limit Revision: 00 Title: ADD-PATH limit capability Document date: 2014-02-07 Group: Individual Submission Pages: 6 URL: = http://www.ietf.org/internet-drafts/draft-francois-idr-addpath-limit-00.t= xt Status: = https://datatracker.ietf.org/doc/draft-francois-idr-addpath-limit/ Htmlized: = http://tools.ietf.org/html/draft-francois-idr-addpath-limit-00 Abstract: In this draft, we propose a new capability that allows BGP speakers supporting ADD-PATH to announce a limit on the number of paths they want to receive from their peers. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From juancamilo.cardona@imdea.org Fri Feb 7 08:31:26 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7950F1AC497 for ; Fri, 7 Feb 2014 08:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6vHr7xASvaJ for ; Fri, 7 Feb 2014 08:31:25 -0800 (PST) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 241F51A03C9 for ; Fri, 7 Feb 2014 08:31:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 5FA571B7032; Fri, 7 Feb 2014 17:31:02 +0100 (CET) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5Q38GxM_UFH; Fri, 7 Feb 2014 17:30:56 +0100 (CET) Received: from GTGNG4J (unknown [193.145.14.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juancamilo.cardona) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id 9810B1B7031; Fri, 7 Feb 2014 17:30:56 +0100 (CET) From: "Juan Camilo Cardona" To: Date: Fri, 7 Feb 2014 17:31:30 +0100 Message-ID: <00d101cf2422$0e5d3070$2b179150$@cardona@imdea.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8kFrkTcm9ZYaL5SY2BYK73YebnuQABO86A Content-Language: es Cc: 'Jeffrey Haas' Subject: [Idr] FW: New Version Notification for draft-francois-idr-rs-addpaths-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:31:26 -0000 Hello all, We just submitted a draft describing the application of ADD-PATH in eBGP = route server scenarios. The document describes the use of ADD-PATH in = order to increase the path diversity received by route server clients. = The draft also discusses some operational practices and errors that = might appear under those environments. Any feedback is appreciated. Best regards, Camilo Cardona -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: viernes, 07 de febrero de 2014 16:11 To: Jeffrey Haas; Jeffrey Haas; Pierre Francois; Adam Simpson; Camilo = Cardona; Adam Simpson; Camilo Cardona; Pierre Francois Subject: New Version Notification for = draft-francois-idr-rs-addpaths-00.txt A new version of I-D, draft-francois-idr-rs-addpaths-00.txt has been successfully submitted by Camilo Cardona and posted to the IETF = repository. Name: draft-francois-idr-rs-addpaths Revision: 00 Title: ADD-PATH for Route Servers Document date: 2014-02-07 Group: Individual Submission Pages: 6 URL: = http://www.ietf.org/internet-drafts/draft-francois-idr-rs-addpaths-00.txt= Status: = https://datatracker.ietf.org/doc/draft-francois-idr-rs-addpaths/ Htmlized: = http://tools.ietf.org/html/draft-francois-idr-rs-addpaths-00 Abstract: BGP speakers in Internet Exchange Points exchange routes with a large number of peers. To reduce the burden of maintaining many sessions, IXPs implement and administrate BGP route servers. Route servers announce to their clients the paths of multiple peers by using a single eBGP session. Route servers, however, are restricted to propagating a single path per NLRI per eBGP session. This constraint affects the path diversity received by clients, which could use paths that they would not have chosen, had they known all possible paths. To overcome this limitation, we propose in this draft the extension of ADD-PATH to eBGP peers in the context of route servers. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From rraszuk@gmail.com Fri Feb 7 09:35:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECD41A041B for ; Fri, 7 Feb 2014 09:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKT8whHLXa3g for ; Fri, 7 Feb 2014 09:35:18 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 38D641A0128 for ; Fri, 7 Feb 2014 09:35:18 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id y1so2865296lam.41 for ; Fri, 07 Feb 2014 09:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6w0ZMK8nTe5gBZe1I0Stu3WqxZeGwJuYUeeUKDz0L0w=; b=NsC0vhNoVofhgI6IjNf3zHU8lSPZWqP4/0+Nh/ExwIGgqUMEzYnBSnSjBVRrIdQpzF lKMK0laYRhQz4NU8dnmxRGUEkFX9wemg/Aioy5whmKjc0vHjZnYifmm53saGooiSz/u1 bb5cr3oN2R9FhRsqvbcq7sxGjp25ZYePgeGzc2hH8Ta+1cmVTRAY9ny/ilOOAc0YZ5BI QlfF0o+2zqhjpLQSx8VvZ50lx7Xd+BYimlYx5CPi3nnyO1ncpMaK0QNGvrS29SlMDj3I 7HAoQB4MVpDlKrormL+i8dIB6KqB7TViLsCm6ANEyxexbat6yZ99tlHKOrzR3S+YVh7T 1CDw== MIME-Version: 1.0 X-Received: by 10.112.34.231 with SMTP id c7mr1792812lbj.56.1391794517399; Fri, 07 Feb 2014 09:35:17 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.51.105 with HTTP; Fri, 7 Feb 2014 09:35:17 -0800 (PST) In-Reply-To: <52f50a63.c5de2a0a.35ae.ffffd669SMTPIN_ADDED_BROKEN@mx.google.com> References: <52f50a63.c5de2a0a.35ae.ffffd669SMTPIN_ADDED_BROKEN@mx.google.com> Date: Fri, 7 Feb 2014 18:35:17 +0100 X-Google-Sender-Auth: NcI0zE6duxMqnT02ObT2Gh_IrPE Message-ID: From: Robert Raszuk To: Juan Camilo Cardona Content-Type: multipart/alternative; boundary=14dae93d94d4cf5e2004f1d46910 Cc: Jeffrey Haas , idr wg Subject: Re: [Idr] FW: New Version Notification for draft-francois-idr-rs-addpaths-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:35:22 -0000 --14dae93d94d4cf5e2004f1d46910 Content-Type: text/plain; charset=ISO-8859-1 Hi Juan & Pierre, Few points on this (as this topic has already been discussed in the past). * It is reasonable to expect that operator would like to adjust such limit on a per AFI/SAFI basis. Since you are using capability for the messaging it and since dynamic capabilities are not practically deployed anywhere this will mean session reset .. including those AFI/SAFI which are not affected. If you ask me how to encode this I would suggest new ORF type and new minor extension to RTC. At least you will be able to adjust the value without breaking things. * For IBGP we always strive to make the number of paths consistent in the AS. That's why there is normally no drop of some paths policy on IBGP keeping IBGP mesh consistent. This is true especially for cases where no encapsulation is used in the domain and excludes SAFI 128 PE where it does drop on IBGP unneeded VPN prefixes. * For EBGP cases one could argue that the below is too strong: " the other party must configure an ADD-PATH mode that does not overload the memory of other device." Clearly there is no MUST ... as such EBGP peer may simply drop over N paths by inbound policy. Therefor sender may still use "send all" mode. Thx, R. On Fri, Feb 7, 2014 at 5:31 PM, Juan Camilo Cardona < juancamilo.cardona@imdea.org> wrote: > Hello all, > > We just submitted a draft describing the application of ADD-PATH in eBGP > route server scenarios. The document describes the use of ADD-PATH in order > to increase the path diversity received by route server clients. The draft > also discusses some operational practices and errors that might appear > under those environments. Any feedback is appreciated. > > Best regards, --14dae93d94d4cf5e2004f1d46910 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Juan
&= Pierre,

Few points on this (as this topic has already been discusse= d in the past).

* It is reasonable to expect that operator would like to adjust such li= mit on a per AFI/SAFI basis. Since you are using capability for the messagi= ng it and since dynamic capabilities are not practically deployed anywhere = this will mean session reset .. including those AFI/SAFI which are not affe= cted.

If you ask me how to encode this I would suggest new ORF type and new m= inor extension to RTC. At least you will be able to adjust the value withou= t breaking things.

* For IBGP we always strive to make the number of= paths consistent in the AS. That's why there is normally no drop of so= me paths policy on IBGP keeping IBGP mesh consistent.
=A0
This is true especially for cases where no encapsulation is used in = the domain
and =A0excludes SAF= I 128 PE where it does drop on IBGP unneeded VPN prefixes.

* For EBGP cases one could argue that the below is too strong:

&= quot; the other party must configure =A0an ADD-PATH mode that does not over= load the memory of other device."

Clearly there is no MUST ... = as such EBGP peer may
simply
drop over N path= s by inbound policy. Therefor sender may still use "send all" mod= e.

Thx,
R.


On Fri, Feb 7, = 2014 at 5:31 PM, Juan Camilo Cardona <juancamilo.cardona@imdea.= org> wrote:
Hello all,

We just submitted a draft describing the application of ADD-PATH in eBGP ro= ute server scenarios. The document describes the use of ADD-PATH in order t= o increase the path diversity received by route server clients. The draft a= lso discusses some operational practices and errors that might appear under= those environments. Any feedback is appreciated.

Best regards,
--14dae93d94d4cf5e2004f1d46910-- From shares@ndzh.com Sun Feb 9 06:34:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2D91A00F5 for ; Sun, 9 Feb 2014 06:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay2UQzTE87rt for ; Sun, 9 Feb 2014 06:34:33 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id ED08C1A030C for ; Sun, 9 Feb 2014 06:34:32 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Sun, 9 Feb 2014 09:34:31 -0500 Message-ID: <004901cf25a4$0bb8fa10$232aee30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01CF257A.22E36740" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8lo/qDv4TVl8r4Tpqm+Rbxv1qeTQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: [Idr] Draft deadline X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 14:34:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004A_01CF257A.22E36740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. Just a warning - this is on Friday this week. Sue ------=_NextPart_000_004A_01CF257A.22E36740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

2014-02-14 (Friday): Internet Draft submission = cut-off (for all

drafts, = including -00) by UTC 23:59, upload using IETF ID Submission =  Tool.

 

Just a warning – this is on Friday this week. =

 

Sue

------=_NextPart_000_004A_01CF257A.22E36740-- From iesg-secretary@ietf.org Mon Feb 10 10:47:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E591A06E9; Mon, 10 Feb 2014 10:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdPk4LA24k6v; Mon, 10 Feb 2014 10:47:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5507B1A0813; Mon, 10 Feb 2014 10:47:43 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210184743.635.23093.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 10:47:43 -0800 Cc: idr mailing list , idr chair , RFC Editor Subject: [Idr] Protocol Action: 'Making Route Flap Damping Usable' to Proposed Standard (draft-ietf-idr-rfd-usable-04.txt) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 18:47:48 -0000 The IESG has approved the following document: - 'Making Route Flap Damping Usable' (draft-ietf-idr-rfd-usable-04.txt) as Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/ Technical Summary BGP Route Flap damping seeks to reduce the BGP churn in routers. First described in operators forms (RIPE, [ripe178]) and RFC2430 it was harsh penalizing sites for being well-connected because topology riches amplified the number of updates. Therefore, many operators turned it off [ripe378]. However, now because new measurements f[plesser2011] indicates a different suppression hold (6000) BGP update rate can be reduced by 19%. Ripe, a European Operator forum, has endorse these new settings [ripe580]. The Japanese operators have reported their use of the new RFD and their desires for implementation [shishio-grow-isp-rfd-implement-survey]. Working Group Summary WG Group had consensus over the last call. During the last call, a suggestion for addition features was made. The chairs/WG suggested this would be a follow-on draft rather than an addition to the current draft. Document Quality Existing implementation of RFD exist in Juniper and Cisco. Protocol deployments [shishio-grow-isp-rfd-implement-survey] found bugs which have been fixed. The Japanese operator and RIPE operator community have reviewed these documents, and the Japanese operator community given the response in [shishio-grow-isp-rfd-implement-survey]. Personnel Shepherd: Susan Hares (WG chair), AD: Stewart Bryant RFC Editor Note The title of Table 1 OLD Default RFD Paramaters of Juniper and Cisco NEW The default RFD parameters for Cisco and Juniper provided for the information of the reader. END From pmattes@juniper.net Mon Feb 10 12:36:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4531A046A for ; Mon, 10 Feb 2014 12:36:47 -0800 (PST) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03ViGHp_HNvc for ; Mon, 10 Feb 2014 12:36:45 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 088B71A0509 for ; Mon, 10 Feb 2014 12:36:44 -0800 (PST) Received: from mail46-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 10 Feb 2014 20:36:44 +0000 Received: from mail46-va3 (localhost [127.0.0.1]) by mail46-va3-R.bigfish.com (Postfix) with ESMTP id 644872E076D for ; Mon, 10 Feb 2014 20:36:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzc85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz18c673hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh9a9j1155h) Received-SPF: pass (mail46-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=pmattes@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(83072002)(90146001)(85852003)(56816005)(81542001)(81342001)(80976001)(83322001)(19580395003)(95666001)(2656002)(87936001)(81686001)(81816001)(85306002)(33646001)(15975445006)(92566001)(87266001)(77096001)(53806001)(51856001)(76796001)(76482001)(54356001)(93136001)(79102001)(31966008)(46102001)(74316001)(77982001)(59766001)(15202345003)(76786001)(76576001)(54316002)(56776001)(76176001)(95416001)(4396001)(47976001)(49866001)(74706001)(74876001)(74662001)(47736001)(50986001)(86362001)(63696002)(69226001)(94316002)(80022001)(66066001)(74502001)(74366001)(65816001)(94946001)(47446002)(93516002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB158; H:BY2PR05MB174.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:FE28E91A.8BF1D948.B9DE6197.1D054D01.20821; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail46-va3 (localhost.localdomain [127.0.0.1]) by mail46-va3 (MessageSwitch) id 13920646023683_19820; Mon, 10 Feb 2014 20:36:42 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.227]) by mail46-va3.bigfish.com (Postfix) with ESMTP id DC340460047 for ; Mon, 10 Feb 2014 20:36:41 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Feb 2014 20:36:37 +0000 Received: from BY2PR05MB158.namprd05.prod.outlook.com (10.242.39.152) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Mon, 10 Feb 2014 20:36:37 +0000 Received: from BY2PR05MB174.namprd05.prod.outlook.com (10.242.39.150) by BY2PR05MB158.namprd05.prod.outlook.com (10.242.39.152) with Microsoft SMTP Server (TLS) id 15.0.873.15; Mon, 10 Feb 2014 20:36:35 +0000 Received: from BY2PR05MB174.namprd05.prod.outlook.com ([169.254.10.150]) by BY2PR05MB174.namprd05.prod.outlook.com ([169.254.10.150]) with mapi id 15.00.0873.009; Mon, 10 Feb 2014 20:36:34 +0000 From: Paul Mattes To: "idr@ietf.org" Thread-Topic: draft-ietf-idr-bgp-enhanced-route-refresh-06 Thread-Index: Ac8mnR6KjY/xM4FtRGaQlyAJB4FeZw== Date: Mon, 10 Feb 2014 20:36:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-forefront-prvs: 0118CD8765 Content-Type: multipart/alternative; boundary="_000_aa1cba6f5345443e94b47ec21e57011eBY2PR05MB174namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Mon, 10 Feb 2014 14:01:14 -0800 Cc: Jeff Haas Subject: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:38:34 -0000 --_000_aa1cba6f5345443e94b47ec21e57011eBY2PR05MB174namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jeff Haas asked me to take a look at the Enhanced Route Refresh draft, and = I had a small grammatical comment. In section 4, paragraph 4, is the text: These route entries comprise of both, the reachability as well as unr= eachability information. This is probably better stated with something like this: These route entries comprise both reachability and unreachability inf= ormation. Thank you. -- pdm --_000_aa1cba6f5345443e94b47ec21e57011eBY2PR05MB174namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Jeff Haas asked me to take a look at the Enhanced Route Refresh draft,= and I had a small grammatical comment.
 
In section 4, paragraph 4, is the text:
These route entries comprise of both, the reac= hability as well as unreachability information.
 
This is probably better stated with something like this:
These route entries comprise both reachability= and unreachability information.
 
Thank you.
 
--
        pdm
 
 
 
 --_000_aa1cba6f5345443e94b47ec21e57011eBY2PR05MB174namprd05pro_-- From bduvivie@cisco.com Tue Feb 11 12:38:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830731A072A for ; Tue, 11 Feb 2014 12:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN8JiZ_0G9np for ; Tue, 11 Feb 2014 12:38:39 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 45D561A0742 for ; Tue, 11 Feb 2014 12:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21082; q=dns/txt; s=iport; t=1392151119; x=1393360719; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XbFFy6xixojnvi2mrbbIhPY4xvElwUMkgnzEiyruQmE=; b=m0PDt5VAhx9lMdyZEG1BhVxhOujQuKM10DNsmCNJciPIbFpkekkbaP7Y VZsMP7qFDX9QII0YNjxek8fLv4DihxGnlDqM9yuZyzPnTkrste61sodxb 9krij3PMyd7Zgmpw8BUmlFpzquh95bMLkg8h0X48GjfAtCfpvHWT02iG/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwGAG2J+lKtJXHB/2dsb2JhbABagkhEOFeqCowpiFOBFRZ0giUBAQEEAQEBKkELDAQCAQgRBAEBAQodBycLEwEJCAIEAQ0FCIdpAxENyFIXjF+BLzotBAYBBoMegRQEiRCNNIMYiyuFQ4Mtgio X-IronPort-AV: E=Sophos;i="4.95,827,1384300800"; d="scan'208,217";a="303398236" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 11 Feb 2014 20:38:38 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1BKcb6h014523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 20:38:37 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.170]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 14:38:35 -0600 From: "Bertrand Duvivier (bduvivie)" To: Robert Raszuk , Pradosh Mohapatra Thread-Topic: [Idr] Flowspec, coexistance of redirect and mirror actions Thread-Index: AQHOo/436d64LadntUuqPTw52t2IbJqxhuZg Date: Tue, 11 Feb 2014 20:38:35 +0000 Message-ID: <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.113.245] Content-Type: multipart/alternative; boundary="_000_5F1FD493E541C642ABBC18EDC327C82F1F4732E7xmbalnx11ciscoc_" MIME-Version: 1.0 Cc: "mtexier@arbor.net" , "idr@ietf.org" , "ju1738@att.com" , Jeff Haas , "David Smith \(djsmith\)" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 20:38:44 -0000 --_000_5F1FD493E541C642ABBC18EDC327C82F1F4732E7xmbalnx11ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I see 2 cases: Signaling primary/backup actions We could control path priority using LP or MED. Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ... Of N path RR could select best 2 or 3 or all best path based on preferred = LP (or MED) BGP Client could select first action, if not possible due to NH not availab= le in RIB, then act on second ... etc... Signaling multiple parallel actions. I don't have answer for this one Bertrand From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: mercredi 28 ao=FBt 2013 16:52 To: Pradosh Mohapatra Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); ju17= 38@att.com Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi Pradosh, 5575 still requires you to run BGP best path selection even if you have mul= tiple paths. This is both for the onward advertisement as well as for the l= ocal installation. You are proposing to install more then "best" path locally which may actual= ly require substantial changes to the BGP operation. How do you control which paths are to be installed let's say which 2 out of= N ? The multipath checks are not really helpful here. It's an interesting question if we in general agree to install multiple pat= hs in flowspec SAFI for the exact same NLRI ? Regards, R. On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra > wrote: Hi Kaliraj, Suggest you use add-path: send two paths for the flow, one with next-hop X and redirect action, the other with next-hop Y and mirror action. - Pradosh ________________________________ From: Kaliraj Vairavakkalai > To: "Simpson, Adam (Adam)" >; "ju1738@att.com" >; "pmohapat@cisco.com" >; "djsmith@cisco.com" >; "H= enderickx, Wim (Wim)" >; "mtexier@arbor.net" > Cc: Jeff Haas >; "idr@ietf.org<= mailto:idr@ietf.org>" > Sent: Tuesday, August 27, 2013 10:55 AM Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI) The devices doing the scrubbing and LI may be different (based on devices' = capability, load-balancing requirement etc), was the thought behind my ques= tion. Thanks, Kaliraj > -----Original Message----- > From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] > Sent: Tuesday, August 27, 2013 10:19 AM > To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapa= t@cisco.com; > djsmith@cisco.com; Henderickx, Wim (Wim); mtexi= er@arbor.net > Cc: Jeff Haas; idr@ietf.org > Subject: Re: Flowspec, coexistance of redirect and mirror actions > > Hi Kaliraj, > > You are correct; these actions are mutually exclusive according to the cu= rrent > encoding. What does it mean for you to have a flow both moved > (redirected) and copied (mirrored)? Do you mean the original flow with > destination A is steered/moved to new destination B while at the same tim= e a > copy of this flow is sent to a new destination C? I personally have not s= een a > requirement for this type of compound action but I will leave the other > authors to comment as well. > > -Adam > > > On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" > wrote: > > >Hi authors, > > > >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > > > >If it is desired to perform both "redirect-action" to a nexthop X, and > >"mirror-action" to a different nexthop Y simultaneously for the same > >flow, how is it achieved? > > > >It appears the signaling for such a scenario may not be handled by the > >mechanisms specified in this draft, unless I am missing something. > >Could you pls clarify. > > > >Thanks > >Kaliraj > > > > _______________________________________________ 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 --_000_5F1FD493E541C642ABBC18EDC327C82F1F4732E7xmbalnx11ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I see 2 cases:

 <= /p>

Signaling primary/back= up actions

 <= /p>

We could control path pri= ority using LP or MED.

Assuming NLRI x PATH 1 AC= TION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, …

 <= /p>

Of N path RR could select= best 2 or 3 or all best path  based on preferred LP (or MED)

BGP Client could select f= irst action, if not possible due to NH not available in RIB, then act on se= cond … etc…

 <= /p>

Signaling multiple par= allel actions.

 <= /p>

I don’t have answer= for this one

 <= /p>

Bertrand

 <= /p>

 <= /p>

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: mercredi 28 ao=FBt 2013 16:52
To: Pradosh Mohapatra
Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith= ); ju1738@att.com
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons

 

= Hi Pradosh,

=  

= 5575 still requires you to run BGP best path selection even if you have mul= tiple paths. This is both for the onward advertisement as well as for the l= ocal installation. 

=  

= You are proposing to install more then "best" path locally which = may actually require substantial changes to the BGP operation. 

=  

= How do you control which paths are to be installed let's say which 2 out of= N ? The multipath checks are not really helpful here. 

=  

= It's an interesting question if we in general agree to install multiple pat= hs in flowspec SAFI for the exact same NLRI ? 

=  

= Regards,

= R.

=  

=  

=  

=  

=  

=  

 

On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra = <mpradosh@yahoo.= com> wrote:

Hi Kaliraj,

 

Suggest you use add-path: send two paths for the flo= w, one with next-hop X 

and redirect action, the other with next-hop Y and m= irror action.

 

- Pradosh

 

From: Kaliraj Vairavakkalai <kaliraj@juniper.net>
To: "Simpson, Adam (Adam)" <adam.simpson@alcatel-lucent.com>; "ju1738@at= t.com" <ju1= 738@att.com>; "pmohapat@cis= co.com" <pmohapat@cisco.com>; "djsmith@cisco.com" <djsmith@cisco.com>; "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>= ;; "mtexier@arb= or.net" <mtexier@arbor.net>
Cc: Jeff Haas <jhaas@juniper.net>; "idr@ietf.org" <idr@ietf.org>
Sent: Tuesday, August 27, 2013 10:55 AM
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons


Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI)

The devices doing the scrubbing and LI may be different (based on devices' = capability, load-balancing requirement etc), was the thought behind my ques= tion.

Thanks,
Kaliraj
> -----Original Message-----
> From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com]
> Sent: Tuesday, August 27, 2013 10:19 AM
> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com<= /a>;
> djsmith@cisco.c= om; Henderickx, Wim (Wim); mtexier@arbor.net
> Cc: Jeff Haas; idr@i= etf.org
> Subject: Re: Flowspec, coexistance of redirect and mirror actions
>
> Hi Kaliraj,
>
> You are correct; these actions are mutually exclusive according to the= current
> encoding. What does it mean for you to have a flow both moved
> (redirected) and copied (mirrored)? Do you mean the original flow with=
> destination A is steered/moved to new destination B while at the same = time a
> copy of this flow is sent to a new destination C? I personally have no= t seen a
> requirement for this type of compound action but I will leave the othe= r
> authors to comment as well.
>
> -Adam
>
>
> On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" <kaliraj@juniper.net&g= t; wrote:
>
> >Hi authors,
> >
> >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02
> >
> >If it is desired to perform both "redirect-action" to a = nexthop X, and
> >"mirror-action" to a different nexthop Y simultaneously = for the same
> >flow, how is it achieved?
> >
> >It appears the signaling for such a scenario may not be handled by= the
> >mechanisms specified in this draft, unless I am missing something.=
> >Could you pls clarify.
> >
> >Thanks
> >Kaliraj
> >
>
>


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


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

 

--_000_5F1FD493E541C642ABBC18EDC327C82F1F4732E7xmbalnx11ciscoc_-- From shares@ndzh.com Tue Feb 11 22:05:29 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63651A07FF for ; Tue, 11 Feb 2014 22:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcRhrFaWxEA5 for ; Tue, 11 Feb 2014 22:05:25 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 56ADA1A07F9 for ; Tue, 11 Feb 2014 22:05:25 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Wed, 12 Feb 2014 01:05:15 -0500 Message-ID: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CF278E.7E1728C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8nuBfxp1gVzO+BQ3yxKS1Cz+xe3A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Cc: idr wg , "'John G. Scudder'" , shares@ndzh.com Subject: [Idr] Call for presentations for IETF X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 06:05:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01CF278E.7E1728C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Please let John and I know if you wish to make a presentation at ietf 89. As always IDR meeting motto is "no draft, no presentation". IDR is on Thursday from 13:00-15:00 GMT. Just respond to this email to request your presentation slot. Sue Hares ------=_NextPart_000_001C_01CF278E.7E1728C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Please let = John and I know if you wish to make a presentation at ietf 89. =

As always IDR meeting motto is = “no draft, no presentation”.

 

IDR is on = Thursday from 13:00-15:00 GMT.   

 

Just respond = to this email to request your presentation slot.

 

Sue = Hares

------=_NextPart_000_001C_01CF278E.7E1728C0-- From thomas.mangin@exa-networks.co.uk Wed Feb 12 01:41:49 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92481A08DA; Wed, 12 Feb 2014 01:41:49 -0800 (PST) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMu0uvgk1TwR; Wed, 12 Feb 2014 01:41:46 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id C80091A08DC; Wed, 12 Feb 2014 01:41:45 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id D57CCA0079; Wed, 12 Feb 2014 09:41:43 +0000 (GMT) Received: from [10.0.1.2] (office.exa-networks.co.uk [82.219.212.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 9741222116B; Wed, 12 Feb 2014 09:41:43 +0000 (GMT) Content-Type: multipart/signed; boundary="Apple-Mail=_E021B8DA-EE73-4078-A789-95A070B836F8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Mangin In-Reply-To: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> Date: Wed, 12 Feb 2014 09:41:42 +0000 Message-Id: <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> References: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> To: idr-bounces@ietf.org X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: idr wg , Susan Hares , "John G. Scudder" Subject: Re: [Idr] Call for presentations for IETF X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 09:41:49 -0000 --Apple-Mail=_E021B8DA-EE73-4078-A789-95A070B836F8 Content-Type: multipart/alternative; boundary="Apple-Mail=_A6F5FCC2-AF4F-40B8-94C2-FA92D620D0A8" --Apple-Mail=_A6F5FCC2-AF4F-40B8-94C2-FA92D620D0A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Even for things like :=20 There is currently 4 (from memory) different draft requiring and = proposing different, incompatible implementations of a TLV format in = BGP. Could some effort be put together to define ONE TLV format, so = implementations do not need to include 4/5 different ones. Could some minor changes be done to last call draft to make their format = compatible with grand generalised TLV format. People may wonder which draft ? :-) - draft-ietf-idr-aigp-10 - draft-frs-bgp-operational-message-00 - draft-raszuk-wide-bgp-communities-03 - And there is surely some more ... Having discussed it quickly with one of the author of the draft above, = the quick overview seems to be : - operational =3D True TLV - aigp =3D almost like operational, but only a single octet for the = type - widecomm =3D Really, TV , no length, and part of the extcommunity = specification So it would seems that with minor modifications, it could be possible. Oh ! Sue, I know the answer is no, and it is great as no one want to = come to its first IETF to take the stage and argue with regular = attendant :-) But at least the question has been asked and hopefully will be discussed = :-) Thomas On 12 Feb 2014, at 06:05, Susan Hares wrote: > Please let John and I know if you wish to make a presentation at ietf = 89. > As always IDR meeting motto is =93no draft, no presentation=94. > =20 > IDR is on Thursday from 13:00-15:00 GMT. =20 > =20 > Just respond to this email to request your presentation slot. > =20 > Sue Hares > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_A6F5FCC2-AF4F-40B8-94C2-FA92D620D0A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Even = for things like : 

There is currently 4 (from = memory) different draft requiring and proposing different, incompatible = implementations of a TLV format in BGP.
Could some effort be put = together to define ONE TLV format, so implementations do not need to = include 4/5 different ones.
Could some minor changes be done = to last call draft to make their format compatible with grand = generalised TLV format.

People may wonder which = draft ? :-)
- draft-ietf-idr-aigp-10
- = draft-frs-bgp-operational-message-00
- = draft-raszuk-wide-bgp-communities-03
- And there is surely = some more ...

Having discussed it quickly with = one of the author of the draft above, the quick overview seems to be = :
 - operational =3D True TLV
 - aigp =3D almost like = operational, but only a single octet for the type
 - widecomm =3D = Really, TV , no length, and part of the extcommunity = specification

So it would seems that with minor = modifications, it could be possible.

Oh ! Sue, = I know the answer is no, and it is great as no one want to come to its = first IETF to take the stage and argue with regular attendant = :-)
But at least the question has been asked and hopefully = will be discussed = :-)

Thomas

On = 12 Feb 2014, at 06:05, Susan Hares <shares@ndzh.com> wrote:

Please let John and = I know if you wish to make a presentation at ietf = 89.
As always IDR meeting motto is = =93no draft, no presentation=94.
 
IDR is on = Thursday from 13:00-15:00 GMT.   
 
Just = respond to this email to request your presentation = slot.
 
Sue = Hares
______________________________________________= _
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_A6F5FCC2-AF4F-40B8-94C2-FA92D620D0A8-- --Apple-Mail=_E021B8DA-EE73-4078-A789-95A070B836F8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlL7QdYACgkQA/52wvuLgaH4TwCgtLrteaK2zUZnAf+FVHtqkGg+ +3gAoLVfeowtwtRoSu0mY4tnfEswcDgC =qs+i -----END PGP SIGNATURE----- --Apple-Mail=_E021B8DA-EE73-4078-A789-95A070B836F8-- From rraszuk@gmail.com Wed Feb 12 01:59:50 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D3E1A0902; Wed, 12 Feb 2014 01:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP6VfFl4nx4I; Wed, 12 Feb 2014 01:59:47 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BF76E1A090F; Wed, 12 Feb 2014 01:59:34 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id u14so6894466lbd.15 for ; Wed, 12 Feb 2014 01:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fvJbXzY9nDjA2tx21Fr+TYOWRLjWJ9PbLimlpGtTQOQ=; b=DTpCEZx09bytgcAy6MKd0a7aMfzA/q0x1SX5E1h+mslXlBMXBPzJP8zKWlyw/28lqS gfxCPozd5Ei7bXUVm73fdy24KlzkH/9WeaFL7/WqWdcEPe7NjfDfDPbO0Wgim8r3PhSn XE40Q80lRDEPugQjcBLdklUOuF7AFJC0DLLtIniH7VTnHsZN96JaIjSQeVNEuSAs/sc/ O3vrbzcDcxNBIbEpgdeUFNRyaZyfESmnjACvb+tviLAdYkNHTpJKyUZXQGaR/QaOaQAJ lFgbreoqLBR9DqUQMvm/gJkJ1JzfW/s1Z7/+flRxlU8N6hzz9SYLQGZsfee9D4YLW3gg Wmkg== MIME-Version: 1.0 X-Received: by 10.152.5.136 with SMTP id s8mr1262436las.55.1392199173293; Wed, 12 Feb 2014 01:59:33 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.51.105 with HTTP; Wed, 12 Feb 2014 01:59:33 -0800 (PST) In-Reply-To: <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> References: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> Date: Wed, 12 Feb 2014 10:59:33 +0100 X-Google-Sender-Auth: g6FCpxs_40Ob-qGiducHs0-dK7A Message-ID: From: Robert Raszuk To: Thomas Mangin Content-Type: multipart/alternative; boundary=047d7b8743a42e4bf604f232a137 Cc: "John G. Scudder" , idr wg , idr-bounces@ietf.org, Susan Hares Subject: Re: [Idr] Call for presentations for IETF X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 09:59:50 -0000 --047d7b8743a42e4bf604f232a137 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, > - widecomm = Really, TV , no length, and part of the extcommunity > specification That is incorrect. It is not part of ext community and the encoding we are defining requires real TLV. Please wait few days till the new revision of the draft is posted. I also do not think that one octet of type would be sufficient. In BGP each attribute requires different parsing code so I am really not sure why you can't have a flag in such parser to read and interpret one or two octet TLVs depending on which attribute they are present at. As you know other protocols can do this already today :) Best regards, R. On Wed, Feb 12, 2014 at 10:41 AM, Thomas Mangin < thomas.mangin@exa-networks.co.uk> wrote: > Even for things like : > > There is currently 4 (from memory) different draft requiring and proposing > different, incompatible implementations of a TLV format in BGP. > Could some effort be put together to define ONE TLV format, so > implementations do not need to include 4/5 different ones. > Could some minor changes be done to last call draft to make their format > compatible with grand generalised TLV format. > > People may wonder which draft ? :-) > - draft-ietf-idr-aigp-10 > - draft-frs-bgp-operational-message-00 > - draft-raszuk-wide-bgp-communities-03 > - And there is surely some more ... > > Having discussed it quickly with one of the author of the draft above, the > quick overview seems to be : > - operational = True TLV > - aigp = almost like operational, but only a single octet for the type > - widecomm = Really, TV , no length, and part of the extcommunity > specification > > So it would seems that with minor modifications, it could be possible. > > Oh ! Sue, I know the answer is no, and it is great as no one want to come > to its first IETF to take the stage and argue with regular attendant :-) > But at least the question has been asked and hopefully will be discussed > :-) > > Thomas > > On 12 Feb 2014, at 06:05, Susan Hares wrote: > > Please let John and I know if you wish to make a presentation at ietf 89. > As always IDR meeting motto is "no draft, no presentation". > > IDR is on Thursday from 13:00-15:00 GMT. > > Just respond to this email to request your presentation slot. > > Sue Hares > _______________________________________________ > 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 > > --047d7b8743a42e4bf604f232a137 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,

>  - widecomm =3D Really, TV , no length, and part o= f the extcommunity 
> specification

That is incorrect. It is not part of ext community and the encod= ing we are defining requires real TLV. Please wait few days till the new re= vision of the draft is posted. 

I also do not t= hink that one octet of type would be sufficient. 

In BGP each attribute requires different parsing code so I am re= ally not sure why you can't have a flag in such parser to read and inte= rpret one or two octet TLVs depending on which attribute they are present a= t. As you know other protocols can do this already today :)

Best regards,R.



On Wed, Feb 12, 2014 at 10:41 AM, Thomas= Mangin <thomas.mangin@exa-networks.co.uk> wr= ote:
Even for= things like : 

There is currently 4 (from memory) = different draft requiring and proposing different, incompatible implementat= ions of a TLV format in BGP.
Could some effort be put together to define ONE TLV format, so implementati= ons do not need to include 4/5 different ones.
Could some minor c= hanges be done to last call draft to make their format compatible with gran= d generalised TLV format.

People may wonder which draft ? :-)
- draft-i= etf-idr-aigp-10
- draft-frs-bgp-operational-message-00
- draft-raszuk= -wide-bgp-communities-03
- And there is surely some more ...<= /div>

Having discussed it quickly with one of the author of t= he draft above, the quick overview seems to be :
 - operational = =3D True TLV
 - aigp =3D almost like operational, but only a single= octet for the type
 - widecomm =3D Really, TV , no length, and part of the extcommunity s= pecification

So it would seems that with minor modif= ications, it could be possible.

Oh ! Sue, I know t= he answer is no, and it is great as no one want to come to its first IETF t= o take the stage and argue with regular attendant :-)
But at least the question has been asked and hopefully will be discuss= ed :-)

Thomas

On 12 Feb 2014, at 06:05, Susan Hares <shares@ndzh.com> wrote:
Please let John and I know if you wis= h to make a presentation at ietf 89.
As always IDR meeting motto is “no draft, no presentation”.<= /u>
 
IDR is on Thursday from 13:00-15:00 GMT.   
 
Just respond to this email to request your presentation slot.=
 
Sue Hares
____________________________= ___________________
Idr mailing list
Idr@ietf= .org
https://www.ietf.org/mailman/= listinfo/idr

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


--047d7b8743a42e4bf604f232a137-- From thomas.mangin@exa-networks.co.uk Wed Feb 12 02:47:42 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA871A0943; Wed, 12 Feb 2014 02:47:42 -0800 (PST) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m2vfim7sOT2; Wed, 12 Feb 2014 02:47:39 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id E31D61A0944; Wed, 12 Feb 2014 02:47:38 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id 92D4EA0087; Wed, 12 Feb 2014 10:47:36 +0000 (GMT) Received: from [10.0.1.2] (office.exa-networks.co.uk [82.219.212.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 4D1D7221168; Wed, 12 Feb 2014 10:47:36 +0000 (GMT) Content-Type: multipart/signed; boundary="Apple-Mail=_408E95BA-5522-4699-A8F9-5C62005B01A7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Mangin In-Reply-To: Date: Wed, 12 Feb 2014 10:47:35 +0000 Message-Id: <7D9E3BF0-0E43-4681-8C3D-FA31FEE1DD2B@exa-networks.co.uk> References: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> To: rraszuk@gmail.com X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "John G. Scudder" , idr wg , idr-bounces@ietf.org, Susan Hares Subject: Re: [Idr] Call for presentations for IETF X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 10:47:43 -0000 --Apple-Mail=_408E95BA-5522-4699-A8F9-5C62005B01A7 Content-Type: multipart/alternative; boundary="Apple-Mail=_68C21941-D562-41BB-83F9-226DFFA8998E" --Apple-Mail=_68C21941-D562-41BB-83F9-226DFFA8998E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Robert. Thank you for your reply. There is no issues having multiple parsers for TLV, I just believe it is = just undesirable, therefore I am throwing the idea that we should try to = limit their numbers. I am not make assumptions about how far this idea can go. I am all for = being practical but as it seems there is a need for a generic TLV = format, so perhaps "we" should try to get it defined (even if informally = to start with, by just having the draft using compatible formats). I = have no set thought on how the TLV should be defined. I just wanted to make authors are aware that work duplication is going = on, both on the RFC definition and more from my POV for the = implementation. I agree that nowadays saving a few bytes for either length or type is = not really worth it and it is safer to plan for extensibility.=20 Sincerely, Thomas On 12 Feb 2014, at 09:59, Robert Raszuk wrote: > Hi Thomas, >=20 > > - widecomm =3D Really, TV , no length, and part of the extcommunity=20= > > specification >=20 > That is incorrect. It is not part of ext community and the encoding we = are defining requires real TLV. Please wait few days till the new = revision of the draft is posted.=20 >=20 > I also do not think that one octet of type would be sufficient.=20 >=20 > In BGP each attribute requires different parsing code so I am really = not sure why you can't have a flag in such parser to read and interpret = one or two octet TLVs depending on which attribute they are present at. = As you know other protocols can do this already today :) >=20 > Best regards, > R. >=20 >=20 >=20 > On Wed, Feb 12, 2014 at 10:41 AM, Thomas Mangin = wrote: > Even for things like :=20 >=20 > There is currently 4 (from memory) different draft requiring and = proposing different, incompatible implementations of a TLV format in = BGP. > Could some effort be put together to define ONE TLV format, so = implementations do not need to include 4/5 different ones. > Could some minor changes be done to last call draft to make their = format compatible with grand generalised TLV format. >=20 > People may wonder which draft ? :-) > - draft-ietf-idr-aigp-10 > - draft-frs-bgp-operational-message-00 > - draft-raszuk-wide-bgp-communities-03 > - And there is surely some more ... >=20 > Having discussed it quickly with one of the author of the draft above, = the quick overview seems to be : > - operational =3D True TLV > - aigp =3D almost like operational, but only a single octet for the = type > - widecomm =3D Really, TV , no length, and part of the extcommunity = specification >=20 > So it would seems that with minor modifications, it could be possible. >=20 > Oh ! Sue, I know the answer is no, and it is great as no one want to = come to its first IETF to take the stage and argue with regular = attendant :-) > But at least the question has been asked and hopefully will be = discussed :-) >=20 > Thomas >=20 > On 12 Feb 2014, at 06:05, Susan Hares wrote: >=20 >> Please let John and I know if you wish to make a presentation at ietf = 89. >> As always IDR meeting motto is =93no draft, no presentation=94. >> =20 >> IDR is on Thursday from 13:00-15:00 GMT. =20 >> =20 >> Just respond to this email to request your presentation slot. >> =20 >> Sue Hares >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 >=20 --Apple-Mail=_68C21941-D562-41BB-83F9-226DFFA8998E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello = Robert.

Thank you for your = reply.

There is no issues having multiple = parsers for TLV, I just believe it is just undesirable, therefore I am = throwing the idea that we should try to limit their = numbers.

I am not make assumptions about how = far this idea can go. I am all for being practical but as it seems there = is a need for a generic TLV format, so perhaps "we" should try to get it = defined (even if informally to start with, by just having the draft = using compatible formats). I have no set thought on how the TLV should = be defined.

I just wanted to make authors = are aware that work duplication is going on, both on the RFC definition = and more from my POV for the implementation.

I = agree that nowadays saving a few bytes for either length or type is not = really worth it and it is safer to plan for = extensibility. 

Sincerely,

Thomas

On 12 Feb 2014, at = 09:59, Robert Raszuk <robert@raszuk.net> = wrote:

Hi = Thomas,

>  - = widecomm =3D Really, TV , no length, and part of the = extcommunity 
> = specification

That is incorrect. = It is not part of ext community and the encoding we are defining = requires real TLV. Please wait few days till the new revision of the = draft is posted. 

I also do = not think that one octet of type would be = sufficient. 

In BGP each = attribute requires different parsing code so I am really not sure why = you can't have a flag in such parser to read and interpret one or two = octet TLVs depending on which attribute they are present at. As you know = other protocols can do this already today :)

Best = regards,
R.



On Wed, Feb 12, 2014 at 10:41 AM, = Thomas Mangin <thomas.mangin@exa-networks.co.uk> = wrote:
Even for things like = : 

There is currently 4 (from memory) different = draft requiring and proposing different, incompatible implementations of = a TLV format in BGP.
Could some effort be put together to define ONE TLV format, so = implementations do not need to include 4/5 different = ones.
Could some minor changes be done to last call draft to = make their format compatible with grand generalised TLV format.

People may wonder which draft ? :-)
- = draft-ietf-idr-aigp-10
- draft-frs-bgp-operational-message-00
- = draft-raszuk-wide-bgp-communities-03
- And there is surely = some more ...

Having discussed it quickly with one of the author = of the draft above, the quick overview seems to be :
 - = operational =3D True TLV
 - aigp =3D almost like operational, = but only a single octet for the type
 - widecomm =3D Really, TV , no length, and part of the = extcommunity specification

So it would seems that = with minor modifications, it could be = possible.

Oh ! Sue, I know the answer is no, = and it is great as no one want to come to its first IETF to take the = stage and argue with regular attendant :-)
But at least the question has been asked and hopefully will be = discussed = :-)

Thomas

On 12 Feb 2014, at 06:05, Susan Hares <shares@ndzh.com> = wrote:

Please let John = and I know if you wish to make a presentation at ietf = 89.
As always IDR meeting motto is =93no draft, no = presentation=94.
 
IDR is on Thursday from 13:00-15:00 GMT.  =  
 
Just respond to this email to request your presentation = slot.
 
Sue = Hares
_____________________________________= __________
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



= --Apple-Mail=_68C21941-D562-41BB-83F9-226DFFA8998E-- --Apple-Mail=_408E95BA-5522-4699-A8F9-5C62005B01A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlL7UUcACgkQA/52wvuLgaH1VACgxQbnO7tPoPRxq8O24urB9zuR +YYAoMAV4RVyNB6wC5JFx43dnZi9cYUa =lvpy -----END PGP SIGNATURE----- --Apple-Mail=_408E95BA-5522-4699-A8F9-5C62005B01A7-- From rraszuk@gmail.com Wed Feb 12 02:58:07 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513BD1A093D; Wed, 12 Feb 2014 02:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK2FfLTikrGU; Wed, 12 Feb 2014 02:58:04 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 713BB1A092F; Wed, 12 Feb 2014 02:58:03 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id z11so5852891lbi.26 for ; Wed, 12 Feb 2014 02:58:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qoqY17UoWJJncMUZ1ut35Q5Yy08agirXMcBwS8FU3oM=; b=ZoN7W3kGWY0J7QPYI44NwE33fnWomhYaVtWuQAxSHjq0aiol2QJi17zJs9EHg30ZDo jEuOSqpAeUPIZidyr01qDQork+nrbFiaqZdZ2ArW5cPVYnR2V4qTCMXTRXb3NYbOx+kS 3O9sqz8dRV2kEzt+cBigq51TDmMiTKwPGz9sqiVb5K6pdRhlvL1Vj6zjPfDYobmzEpq+ 9QjfZX8+/JcWPPVMcIIpsdyJyQNEyJJU8XSle7McJ2Vfu38NRL7Vak1LP7p2fy5mzdF8 xf1eaPgfrMlKEn+PNu2EOrOy9lh4uFdn8qy75bu0HqMyjVKWqUBoEDc2JdWmL8rLbat9 y+Fg== MIME-Version: 1.0 X-Received: by 10.112.45.108 with SMTP id l12mr29503892lbm.21.1392202681867; Wed, 12 Feb 2014 02:58:01 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.51.105 with HTTP; Wed, 12 Feb 2014 02:58:01 -0800 (PST) In-Reply-To: <7D9E3BF0-0E43-4681-8C3D-FA31FEE1DD2B@exa-networks.co.uk> References: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> <7D9E3BF0-0E43-4681-8C3D-FA31FEE1DD2B@exa-networks.co.uk> Date: Wed, 12 Feb 2014 11:58:01 +0100 X-Google-Sender-Auth: iTKWersmkjo4F37VuwBvM_ivt1k Message-ID: From: Robert Raszuk To: Thomas Mangin Content-Type: multipart/alternative; boundary=001a1134bfc84f109604f2337243 Cc: "John G. Scudder" , idr wg , idr-bounces@ietf.org, Susan Hares Subject: Re: [Idr] Call for presentations for IETF X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 10:58:07 -0000 --001a1134bfc84f109604f2337243 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, I understand and may even like your suggestion regardless how easy or hard would be to converge with everyone on it. The only immediate problem for IDR chairs assuming they also would support unified TLV format across all attributes would be to halt any progress of AIGP attribute draft with its slim TLV proposal till we have a common agreement on the TLV format in IDR. Otherwise I am afraid it is just too late ;) Cheers, R. On Wed, Feb 12, 2014 at 11:47 AM, Thomas Mangin < thomas.mangin@exa-networks.co.uk> wrote: > Hello Robert. > > Thank you for your reply. > > There is no issues having multiple parsers for TLV, I just believe it is > just undesirable, therefore I am throwing the idea that we should try to > limit their numbers. > > I am not make assumptions about how far this idea can go. I am all for > being practical but as it seems there is a need for a generic TLV format, > so perhaps "we" should try to get it defined (even if informally to start > with, by just having the draft using compatible formats). I have no set > thought on how the TLV should be defined. > > I just wanted to make authors are aware that work duplication is going on, > both on the RFC definition and more from my POV for the implementation. > > I agree that nowadays saving a few bytes for either length or type is not > really worth it and it is safer to plan for extensibility. > > Sincerely, > > Thomas > > On 12 Feb 2014, at 09:59, Robert Raszuk wrote: > > Hi Thomas, > > > - widecomm = Really, TV , no length, and part of the extcommunity > > specification > > That is incorrect. It is not part of ext community and the encoding we are > defining requires real TLV. Please wait few days till the new revision of > the draft is posted. > > I also do not think that one octet of type would be sufficient. > > In BGP each attribute requires different parsing code so I am really not > sure why you can't have a flag in such parser to read and interpret one or > two octet TLVs depending on which attribute they are present at. As you > know other protocols can do this already today :) > > Best regards, > R. > > > > On Wed, Feb 12, 2014 at 10:41 AM, Thomas Mangin < > thomas.mangin@exa-networks.co.uk> wrote: > >> Even for things like : >> >> There is currently 4 (from memory) different draft requiring and >> proposing different, incompatible implementations of a TLV format in BGP. >> Could some effort be put together to define ONE TLV format, so >> implementations do not need to include 4/5 different ones. >> Could some minor changes be done to last call draft to make their format >> compatible with grand generalised TLV format. >> >> People may wonder which draft ? :-) >> - draft-ietf-idr-aigp-10 >> - draft-frs-bgp-operational-message-00 >> - draft-raszuk-wide-bgp-communities-03 >> - And there is surely some more ... >> >> Having discussed it quickly with one of the author of the draft above, >> the quick overview seems to be : >> - operational = True TLV >> - aigp = almost like operational, but only a single octet for the type >> - widecomm = Really, TV , no length, and part of the extcommunity >> specification >> >> So it would seems that with minor modifications, it could be possible. >> >> Oh ! Sue, I know the answer is no, and it is great as no one want to come >> to its first IETF to take the stage and argue with regular attendant :-) >> But at least the question has been asked and hopefully will be discussed >> :-) >> >> Thomas >> >> On 12 Feb 2014, at 06:05, Susan Hares wrote: >> >> Please let John and I know if you wish to make a presentation at ietf 89. >> As always IDR meeting motto is "no draft, no presentation". >> >> IDR is on Thursday from 13:00-15:00 GMT. >> >> Just respond to this email to request your presentation slot. >> >> Sue Hares >> _______________________________________________ >> 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 >> >> > > --001a1134bfc84f109604f2337243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,

I understand and may even like your suggestion regardless how easy or hard = would be to converge with everyone on it. 

The only immediate problem for IDR chairs assuming they also would support = unified TLV format across all attributes would be to halt any progress of A= IGP attribute draft with its slim TLV proposal till we have a common agreem= ent on the TLV format in IDR. 

Otherwise I am afraid it is just too = late ;)

Cheers,
R.



On Wed, Feb 12, 2014 at 11:47 AM, Thomas Mangin <thomas.= mangin@exa-networks.co.uk> wrote:
Hello Ro= bert.

Thank you for your reply.

There is no issues having multiple parsers for TLV, I just believe it is ju= st undesirable, therefore I am throwing the idea that we should try to limi= t their numbers.

I am not make assumptions about h= ow far this idea can go. I am all for being practical but as it seems there= is a need for a generic TLV format, so perhaps "we" should try t= o get it defined (even if informally to start with, by just having the draf= t using compatible formats). I have no set thought on how the TLV should be= defined.

I just wanted to make authors are aware that work= duplication is going on, both on the RFC definition and more from my POV f= or the implementation.

I agree that nowadays savin= g a few bytes for either length or type is not really worth it and it is sa= fer to plan for extensibility. 

Sincerely,

Thomas

On 12 Feb 2014, at 09:59, Rob= ert Raszuk <rober= t@raszuk.net> wrote:

Hi T= homas,

>  - widecomm =3D Really, TV , no length, and part o= f the extcommunity 
> specification

That is incorrect. It is not part of ext community and the encod= ing we are defining requires real TLV. Please wait few days till the new re= vision of the draft is posted. 

I also do not t= hink that one octet of type would be sufficient. 

In BGP each attribute requires different parsing code so I am re= ally not sure why you can't have a flag in such parser to read and inte= rpret one or two octet TLVs depending on which attribute they are present a= t. As you know other protocols can do this already today :)

Best regards,R.



On Wed, Feb 12, 2014 at 10:41 AM, Thomas= Mangin <thomas.mangin@exa-networks.co.uk> wr= ote:
Even for= things like : 

There is currently 4 (from memory) = different draft requiring and proposing different, incompatible implementat= ions of a TLV format in BGP.
Could some effort be put together to define ONE TLV format, so implementati= ons do not need to include 4/5 different ones.
Could some minor c= hanges be done to last call draft to make their format compatible with gran= d generalised TLV format.

People may wonder which draft ? :-)
- draft-i= etf-idr-aigp-10
- draft-frs-bgp-operational-message-00
- draft-raszuk= -wide-bgp-communities-03
- And there is surely some more ...<= /div>

Having discussed it quickly with one of the author of t= he draft above, the quick overview seems to be :
 - operational = =3D True TLV
 - aigp =3D almost like operational, but only a single= octet for the type
 - widecomm =3D Really, TV , no length, and part of the extcommunity s= pecification

So it would seems that with minor modif= ications, it could be possible.

Oh ! Sue, I know t= he answer is no, and it is great as no one want to come to its first IETF t= o take the stage and argue with regular attendant :-)
But at least the question has been asked and hopefully will be discuss= ed :-)

Thomas

On 12 Feb 2014, at 06:05, Susan Hares <shares@ndzh.com> wrote:

Please let John and I know if you wish to make a presen= tation at ietf 89.
As always IDR meeting motto is “no draft, no presentation”.<= /u>
 
IDR is on Thursday from 13:00-15:00 GMT.   
 
Just respond to this email to request your presentation slot.=
 
Sue Hares
__________________________________= _____________
Idr mailing list
Idr@ietf.org<= /a>
https://www.ietf.org/mailman/= listinfo/idr


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




--001a1134bfc84f109604f2337243-- From jhaas@slice.pfrc.org Wed Feb 12 08:00:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44E91A08D1; Wed, 12 Feb 2014 08:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXEgQv1HBmHy; Wed, 12 Feb 2014 08:00:13 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 80DF31A09D0; Wed, 12 Feb 2014 08:00:13 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9F78CC23D; Wed, 12 Feb 2014 11:00:12 -0500 (EST) Date: Wed, 12 Feb 2014 11:00:12 -0500 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140212160012.GC12880@pfrc> References: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> <7D9E3BF0-0E43-4681-8C3D-FA31FEE1DD2B@exa-networks.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr wg , Susan Hares , "John G. Scudder" , idr-bounces@ietf.org Subject: Re: [Idr] Call for presentations for IETF X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:00:16 -0000 On Wed, Feb 12, 2014 at 11:58:01AM +0100, Robert Raszuk wrote: > I understand and may even like your suggestion regardless how easy or hard > would be to converge with everyone on it. Something I'd be fine with is a push toward an IDR-blessed Length consistency. Is the TL part of the length or not? This is the item that has varied across the specs the most. In terms of a generic TLV, I think it has more to do with how BGP has traditionally defined a route as some NLRI that share a common set of Path Attributes. I don't know that there's been much call for "and other non-route related stuff" in BGP, at least for UPDATES. > The only immediate problem for IDR chairs assuming they also would support > unified TLV format across all attributes would be to halt any progress of > AIGP attribute draft with its slim TLV proposal till we have a common > agreement on the TLV format in IDR. I think individuals who push too hard to change aigp, even though it's aberrant formatting, should be cautious in the halls of IETF. There are operators that will get extremely upset if we break their running feature. -- Jeff From shares@ndzh.com Wed Feb 12 08:12:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F091A05E1; Wed, 12 Feb 2014 08:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnmeFNsmEh2E; Wed, 12 Feb 2014 08:12:39 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1A11A0545; Wed, 12 Feb 2014 08:12:38 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Thomas Mangin'" , References: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> In-Reply-To: <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> Date: Wed, 12 Feb 2014 11:12:28 -0500 Message-ID: <00a301cf280d$3a1da160$ae58e420$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A4_01CF27E3.514ACDB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK14vKiBteiQxuN7ghpJ0n0aQ26zAIYSuJYmNOPxpA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' , "'John G. Scudder'" Subject: Re: [Idr] Call for presentations for IETF X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:12:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A4_01CF27E3.514ACDB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thomas: You are welcome to discuss these issues on the list. I will bring up your concern during my summary slide of the drafts. The reason for drafts is that so people can see your pros-cons prior to the meeting. Or if they remote, understand your points clearly. Many BGP drafts are often 1 or 2 pages of text surrounded by boiler plate. You could even name it "mangin-1-TLV-Please". AIGP did a have two series of WG last calls and was approved. It has 3+ implementations. I am still crafting the shepherds report this weekend (after IETF drafts close), so the list discussion is helpful. Sue From: Thomas Mangin [mailto:thomas.mangin@exa-networks.co.uk] Sent: Wednesday, February 12, 2014 4:42 AM To: idr-bounces@ietf.org Cc: idr wg; John G. Scudder; Susan Hares Subject: Re: [Idr] Call for presentations for IETF Even for things like : There is currently 4 (from memory) different draft requiring and proposing different, incompatible implementations of a TLV format in BGP. Could some effort be put together to define ONE TLV format, so implementations do not need to include 4/5 different ones. Could some minor changes be done to last call draft to make their format compatible with grand generalised TLV format. People may wonder which draft ? :-) - draft-ietf-idr-aigp-10 - draft-frs-bgp-operational-message-00 - draft-raszuk-wide-bgp-communities-03 - And there is surely some more ... Having discussed it quickly with one of the author of the draft above, the quick overview seems to be : - operational = True TLV - aigp = almost like operational, but only a single octet for the type - widecomm = Really, TV , no length, and part of the extcommunity specification So it would seems that with minor modifications, it could be possible. Oh ! Sue, I know the answer is no, and it is great as no one want to come to its first IETF to take the stage and argue with regular attendant :-) But at least the question has been asked and hopefully will be discussed :-) Thomas On 12 Feb 2014, at 06:05, Susan Hares wrote: Please let John and I know if you wish to make a presentation at ietf 89. As always IDR meeting motto is "no draft, no presentation". IDR is on Thursday from 13:00-15:00 GMT. Just respond to this email to request your presentation slot. Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_00A4_01CF27E3.514ACDB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thomas:

 

You are welcome to discuss these issues on the list.   I = will bring up your concern during my summary slide of the drafts. =

 

The reason for drafts is that so people can see your pros-cons prior = to the meeting. Or if they remote, understand your points clearly.  =  Many BGP drafts  are often 1 or 2 pages of text surrounded by = boiler plate.  You could even name it  = “mangin-1-TLV-Please”.   

 

AIGP did a have two series of WG last calls and was approved. =  It has 3+ implementations. I am still crafting the shepherds = report this weekend (after IETF drafts close), so the list discussion is = helpful.

 

Sue

 

From:= = Thomas Mangin [mailto:thomas.mangin@exa-networks.co.uk]
Sent: = Wednesday, February 12, 2014 4:42 AM
To: = idr-bounces@ietf.org
Cc: idr wg; John G. Scudder; Susan = Hares
Subject: Re: [Idr] Call for presentations for = IETF

 

Even for = things like : 

 

There is currently 4 (from memory) different draft = requiring and proposing different, incompatible implementations of a TLV = format in BGP.

Could some effort = be put together to define ONE TLV format, so implementations do not need = to include 4/5 different ones.

Could some minor changes be done to last call draft to = make their format compatible with grand generalised TLV = format.

 

People may wonder which draft ? = :-)

- = draft-ietf-idr-aigp-10
- draft-frs-bgp-operational-message-00
- = draft-raszuk-wide-bgp-communities-03

- And there is surely some more = ...

 

Having discussed it quickly with one of the author of = the draft above, the quick overview seems to be :

 - operational =3D True TLV
 - aigp =3D = almost like operational, but only a single octet for the type
 - = widecomm =3D Really, TV , no length, and part of the extcommunity = specification

 

So it would seems that with minor modifications, it = could be possible.

 

Oh ! Sue, I know the answer is no, and it is great as = no one want to come to its first IETF to take the stage and argue with = regular attendant :-)

But = at least the question has been asked and hopefully will be discussed = :-)

 

Thomas

 

On 12 Feb 2014, at 06:05, Susan Hares <shares@ndzh.com> = wrote:



Please let = John and I know if you wish to make a presentation at ietf = 89.

As always = IDR meeting motto is “no draft, no = presentation”.

 =

IDR is on = Thursday from 13:00-15:00 GMT.  =  

 =

Just = respond to this email to request your presentation = slot.

 =

Sue = Hares

__________= _____________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

------=_NextPart_000_00A4_01CF27E3.514ACDB0-- From ju1738@att.com Wed Feb 12 08:16:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFC81A05D5; Wed, 12 Feb 2014 08:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCMGCt-oB53K; Wed, 12 Feb 2014 08:16:03 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9F61A03B4; Wed, 12 Feb 2014 08:16:03 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 24e9bf25.2ac117ec5940.463588.00-2487.1296269.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 12 Feb 2014 16:16:02 +0000 (UTC) X-MXL-Hash: 52fb9e425f940c7d-66fa43d6c5b0731798fd29b5b4a0e0c592ffaa74 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id a3e9bf25.0.463500.00-2307.1295982.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 12 Feb 2014 16:15:55 +0000 (UTC) X-MXL-Hash: 52fb9e3b51f52c61-e67482d2446e535e45017b43e7b9f4a83c27d0d0 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1CGFrSN027150; Wed, 12 Feb 2014 11:15:54 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1CGFiYT026943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Feb 2014 11:15:48 -0500 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 12 Feb 2014 16:15:24 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0174.001; Wed, 12 Feb 2014 11:15:24 -0500 From: "UTTARO, JAMES" To: Jeffrey Haas , Robert Raszuk Thread-Topic: [Idr] Call for presentations for IETF Thread-Index: AQHPKAuPFDNNSNkK1EyytWVodRSzHJqxyvhg Date: Wed, 12 Feb 2014 16:15:24 +0000 Message-ID: References: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> <7D9E3BF0-0E43-4681-8C3D-FA31FEE1DD2B@exa-networks.co.uk> <20140212160012.GC12880@pfrc> In-Reply-To: <20140212160012.GC12880@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=7tet2ZkWkOkA:10 a=ofMgfj31e3cA:10 a=mou7VEvB9NQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=dc_zE3XczkcA:10 a=48vgC7mUAAAA:8 a=PvV5v6qhGsd9at] X-AnalysisOut: [8deK8A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=U8qZ8tdgfp_] X-AnalysisOut: [EWrq2:21 a=SlP2wWgr_gls9thC:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Cc: idr wg , "John G. Scudder" , Susan Hares , "idr-bounces@ietf.org" Subject: Re: [Idr] Call for presentations for IETF X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:16:06 -0000 Comments In-Line.. Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, February 12, 2014 11:00 AM To: Robert Raszuk Cc: idr wg; Susan Hares; John G. Scudder; idr-bounces@ietf.org Subject: Re: [Idr] Call for presentations for IETF On Wed, Feb 12, 2014 at 11:58:01AM +0100, Robert Raszuk wrote: > I understand and may even like your suggestion regardless how easy or har= d > would be to converge with everyone on it. Something I'd be fine with is a push toward an IDR-blessed Length consistency. Is the TL part of the length or not? This is the item that has varied across the specs the most. In terms of a generic TLV, I think it has more to do with how BGP has traditionally defined a route as some NLRI that share a common set of Path Attributes. I don't know that there's been much call for "and other non-route related stuff" in BGP, at least for UPDATES. > The only immediate problem for IDR chairs assuming they also would suppor= t > unified TLV format across all attributes would be to halt any progress of > AIGP attribute draft with its slim TLV proposal till we have a common > agreement on the TLV format in IDR. I think individuals who push too hard to change aigp, even though it's aberrant formatting, should be cautious in the halls of IETF. There are operators that will get extremely upset if we break their running feature. [Jim U>] +1=20 -- Jeff _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From thomas.mangin@exa-networks.co.uk Wed Feb 12 08:49:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382EC1A09B0; Wed, 12 Feb 2014 08:49:16 -0800 (PST) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTODH2aEUm7Q; Wed, 12 Feb 2014 08:49:12 -0800 (PST) Received: from out-7.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2417F1A09B4; Wed, 12 Feb 2014 08:49:06 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-7.mail.exa.net.uk (ExaSMTPD) with ESMTP id F1747A0089; Wed, 12 Feb 2014 16:49:04 +0000 (GMT) Received: from [10.0.1.2] (office.exa-networks.co.uk [82.219.212.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 9F50A6C0048; Wed, 12 Feb 2014 16:49:04 +0000 (GMT) Content-Type: multipart/signed; boundary="Apple-Mail=_CC1C030A-B086-4CFB-BEA7-05EE3931DA24"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Mangin In-Reply-To: <00a301cf280d$3a1da160$ae58e420$@ndzh.com> Date: Wed, 12 Feb 2014 16:49:03 +0000 Message-Id: <18BC300A-44BC-4847-8A55-BBB8AD48050A@exa-networks.co.uk> References: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> <00a301cf280d$3a1da160$ae58e420$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: idr wg , idr-bounces@ietf.org, "John G. Scudder" Subject: Re: [Idr] Call for presentations for IETF X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:49:16 -0000 --Apple-Mail=_CC1C030A-B086-4CFB-BEA7-05EE3931DA24 Content-Type: multipart/alternative; boundary="Apple-Mail=_0261A83A-EBBC-4E36-85AB-47901E0AA45B" --Apple-Mail=_0261A83A-EBBC-4E36-85AB-47901E0AA45B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Susan, Thank you for your help. This is not an hot topic, BGP can live with disparate TLV format .. It = just seems ... messy to me :-) I fear I will not have time to write my first draft for London but if = enough think it is worth some discussion time, I will find a way to make = it happen .. I just believe I may just regret this statement :-) Otherwise I am happy to speak about it informally, all what is needed is = "rough consensus" of the current draft writer to update their document = the same way :-) I agree that AIGP is now way too far down the line for changes ... I = listed it as it is using a TLV format ...=20 But it may not be the same for all others drafts :-) Thomas On 12 Feb 2014, at 16:12, Susan Hares wrote: > Thomas: > =20 > You are welcome to discuss these issues on the list. I will bring up = your concern during my summary slide of the drafts. > =20 > The reason for drafts is that so people can see your pros-cons prior = to the meeting. Or if they remote, understand your points clearly. = Many BGP drafts are often 1 or 2 pages of text surrounded by boiler = plate. You could even name it =93mangin-1-TLV-Please=94. =20 > =20 > AIGP did a have two series of WG last calls and was approved. It has = 3+ implementations. I am still crafting the shepherds report this = weekend (after IETF drafts close), so the list discussion is helpful. > =20 > Sue > =20 > From: Thomas Mangin [mailto:thomas.mangin@exa-networks.co.uk]=20 > Sent: Wednesday, February 12, 2014 4:42 AM > To: idr-bounces@ietf.org > Cc: idr wg; John G. Scudder; Susan Hares > Subject: Re: [Idr] Call for presentations for IETF > =20 > Even for things like :=20 > =20 > There is currently 4 (from memory) different draft requiring and = proposing different, incompatible implementations of a TLV format in = BGP. > Could some effort be put together to define ONE TLV format, so = implementations do not need to include 4/5 different ones. > Could some minor changes be done to last call draft to make their = format compatible with grand generalised TLV format. > =20 > People may wonder which draft ? :-) > - draft-ietf-idr-aigp-10 > - draft-frs-bgp-operational-message-00 > - draft-raszuk-wide-bgp-communities-03 > - And there is surely some more ... > =20 > Having discussed it quickly with one of the author of the draft above, = the quick overview seems to be : > - operational =3D True TLV > - aigp =3D almost like operational, but only a single octet for the = type > - widecomm =3D Really, TV , no length, and part of the extcommunity = specification > =20 > So it would seems that with minor modifications, it could be possible. > =20 > Oh ! Sue, I know the answer is no, and it is great as no one want to = come to its first IETF to take the stage and argue with regular = attendant :-) > But at least the question has been asked and hopefully will be = discussed :-) > =20 > Thomas > =20 > On 12 Feb 2014, at 06:05, Susan Hares wrote: >=20 >=20 > Please let John and I know if you wish to make a presentation at ietf = 89. > As always IDR meeting motto is =93no draft, no presentation=94. > =20 > IDR is on Thursday from 13:00-15:00 GMT. =20 > =20 > Just respond to this email to request your presentation slot. > =20 > Sue Hares > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_0261A83A-EBBC-4E36-85AB-47901E0AA45B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello = Susan,

Thank you for your = help.

This is not an hot topic, BGP can = live with disparate TLV format .. It just seems ... messy to me = :-)

I fear I will not have time to write = my first draft for London but if enough think it is worth some = discussion time, I will find a way to make it happen .. I just believe I = may just regret this statement :-)

Otherwise I = am happy to speak about it informally, all what is needed is "rough = consensus" of the current draft writer to update their document the same = way :-)

I agree that AIGP is now way too far = down the line for changes ...  I listed it as it is using a TLV = format  ... 
But it may not be the same for all = others drafts = :-)

Thomas


Thomas:
 
You are welcome to = discuss these issues on the list.   I will bring up your = concern during my summary slide of the = drafts.
 
The reason for drafts is that so people can see your = pros-cons prior to the meeting. Or if they remote, understand your = points clearly.   Many BGP drafts  are often 1 or 2 pages = of text surrounded by boiler plate.  You could even name it  = =93mangin-1-TLV-Please=94.   
 
AIGP did a have two = series of WG last calls and was approved.  It has 3+ = implementations. I am still crafting the shepherds report this weekend = (after IETF drafts close), so the list discussion is = helpful.
 
Sue
 
From: Thomas Mangin [mailto:thomas.mangin@exa-= networks.co.uk] 
Sent: Wednesday, February 12, = 2014 4:42 AM
To: idr-bounces@ietf.org
Cc: idr wg; John G. = Scudder; Susan Hares
Subject: Re: [Idr] Call for = presentations for IETF
 
Even = for things like : 
 
There = is currently 4 (from memory) different draft requiring and proposing = different, incompatible implementations of a TLV format in = BGP.
Could some = effort be put together to define ONE TLV format, so implementations do = not need to include 4/5 different ones.
Could some minor changes be done to last call draft = to make their format compatible with grand generalised TLV = format.
 
People may wonder which draft ? = :-)
- = draft-ietf-idr-aigp-10
- draft-frs-bgp-operational-message-00
- = draft-raszuk-wide-bgp-communities-03
- And there is surely some more = ...
 
Having discussed it quickly with one of the author of the draft = above, the quick overview seems to be :
 - operational =3D True TLV
 - aigp =3D = almost like operational, but only a single octet for the type
 - = widecomm =3D Really, TV , no length, and part of the extcommunity = specification
 
So it = would seems that with minor modifications, it could be = possible.
 
Oh ! = Sue, I know the answer is no, and it is great as no one want to come to = its first IETF to take the stage and argue with regular attendant = :-)
But at least = the question has been asked and hopefully will be discussed = :-)
 
Thomas
 
On 12 = Feb 2014, at 06:05, Susan Hares <shares@ndzh.com> wrote:


Please let John and I know if you wish to make a = presentation at ietf 89.
As always IDR meeting motto is =93no draft, no = presentation=94.
 
IDR is on Thursday from 13:00-15:00 GMT.  =  
 
Just respond to this email to request your = presentation slot.
 
Sue Hares
_______________________________________________
Idr = mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
=

= --Apple-Mail=_0261A83A-EBBC-4E36-85AB-47901E0AA45B-- --Apple-Mail=_CC1C030A-B086-4CFB-BEA7-05EE3931DA24 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlL7pf8ACgkQA/52wvuLgaGwSACgxxzq4QBrIJoNxpaC9qA3EOTd eWAAoMPtwXfTuMd2u8cyN9CYo2yUtAIP =CVW0 -----END PGP SIGNATURE----- --Apple-Mail=_CC1C030A-B086-4CFB-BEA7-05EE3931DA24-- From santiago@crfreenet.org Thu Feb 13 07:32:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D909D1A02D9 for ; Thu, 13 Feb 2014 07:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoyfZSd28FPc for ; Thu, 13 Feb 2014 07:32:11 -0800 (PST) Received: from mail.crfreenet.org (mail6.crfreenet.org [IPv6:2002:515c:9101:20::10]) by ietfa.amsl.com (Postfix) with ESMTP id 088BB1A0291 for ; Thu, 13 Feb 2014 07:32:10 -0800 (PST) Received: from localhost (ip-89-102-22-52.net.upcbroadband.cz [89.102.22.52]) by mail.crfreenet.org (Postfix) with ESMTP id 6CCC4FCCF for ; Thu, 13 Feb 2014 16:32:05 +0100 (CET) Received: from santiago by localhost with local (Exim 4.69) (envelope-from ) id 1WDyoJ-0004WM-7L for idr@ietf.org; Thu, 13 Feb 2014 17:06:47 +0100 Date: Thu, 13 Feb 2014 17:06:47 +0100 From: Ondrej Zajicek To: idr@ietf.org Message-ID: <20140213160647.GZ13804@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vYzPTKoKRdF40tnF" Content-Disposition: inline X-Operating-System: Debian GNU/Linux User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Idr] Possible problem in RFC 4724 Graceful restart? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:32:15 -0000 --vYzPTKoKRdF40tnF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi If i understand correctly RFC 4724 Graceful restart, then the modifications of FSM restricted the collision detection from RFC 4271 6.8.: However, if the Graceful Restart Capability with one or more AFIs/SAFIs has been received for the session, then in response to Event 16 or Event 17 the local system: ... - drops the TCP connection associated with the ESTABLISHED ... If BGP speakers R1 and R2 simultaneously tries to establish BGP sessions and the first connection advanced to Established state before the second connection set up the TCP connection, then the situation depends on how R1 and R2 are configured: 1) If both R1 and R2 do not support RFC 4724, then the second connection is ditched by collision detection. 2) If both R1 and R2 have fully active graceful restart, then the collision is handled as if both speakers restarted, first connection is ditched as mentioned above and the second advances to established. 3) But if both R1 and R2 support graceful restart, but R1 is configured as receiver-only, then R1 closes the first connection (according to RFC 4724), but R2 simultaneously closes the second connection (because R1 announces graceful restart capability without any AFI/SAFI, therefore modifications of FSM from RFC 4724 do not apply). After that both speakers realise that the other connection is also down and after some timeout they would try to reestablish the session, perhaps with the same result. Is such problem possible, or i am misinterpreting RFC 4724? --=20 Ondrej 'SanTiago' Zajicek --vYzPTKoKRdF40tnF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAlL87ZcACgkQw1GB2RHercNz7gCeNVMz4im4XG4kWN8JKt/m+zHP 3rAAnAq9zeNSsTQfyYaPNiodQk9xyn7s =SaXR -----END PGP SIGNATURE----- --vYzPTKoKRdF40tnF-- From jakob.heitz@ericsson.com Thu Feb 13 07:36:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E031A02C6 for ; Thu, 13 Feb 2014 07:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_irqq6adtMF for ; Thu, 13 Feb 2014 07:36:35 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id EE40D1A02F0 for ; Thu, 13 Feb 2014 07:36:31 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-78-52fce67a01b9 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id D1.02.12743.B76ECF25; Thu, 13 Feb 2014 16:36:27 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 10:36:29 -0500 From: Jakob Heitz To: Ondrej Zajicek Thread-Topic: [Idr] Possible problem in RFC 4724 Graceful restart? Thread-Index: AQHPKNDMs4/KziSdVEOsoDJB7V9Zk5qzURic Date: Thu, 13 Feb 2014 15:36:29 +0000 Message-ID: References: <20140213160647.GZ13804@localhost> In-Reply-To: <20140213160647.GZ13804@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyuXRPlG71sz9BBl82CFm8uv2MyeJ5w29G ByaPlxtWMXksWfKTKYApissmJTUnsyy1SN8ugStjVct5toIr/BXHm66wNDAe5Oli5OSQEDCR +PH8DzuELSZx4d56ti5GLg4hgSOMEvcPTmeCcJYzSjw++ooZpIpNQEfi2/UuMFtEQFviUuNR MJtZQFHi4t8OJhBbWMBR4uL3B0A2B1CNk8S/TV4Q5UYSZ5vWsYCEWQRUJV6ccwUJ8wrYS7T+ PwxWLSSgJ3F9lzZImFNAX+Lr2QOsIDYj0GnfT61hglgkLnHryXwmiJMFJJbsOc8MYYtKvHz8 jxWiRkdiwe5PbBC2tsSyha+ZIVYJSpyc+YRlAqPoLCSjZiFpmYWkZRaSlgWMLKsYOUqLU8ty 040MNjECI+GYBJvuDsY9Ly0PMUpzsCiJ83556xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gbHpygwGrnaHy4Ud6mz2B00upx/UZgs80nn5j/Xjg//d4tPk2UK4knLKT3t5RaxoWfllVavQ C5mEtYYeG8s/fbKfOWHaxY4kR4NXx2+funIs3ejiLp7ecJen32fcyJs/65BxVo2LYutFbeFz ba9chULm8657USUarO0mJZLKuMn2nFzre8G420osxRmJhlrMRcWJAKthFYFSAgAA Cc: "idr@ietf.org" Subject: Re: [Idr] Possible problem in RFC 4724 Graceful restart? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:36:38 -0000 Nice! However, unlikely and completely recoverable if it does happen. -- Jakob Heitz. > On Feb 13, 2014, at 7:32 AM, "Ondrej Zajicek" wr= ote: >=20 > Hi >=20 > If i understand correctly RFC 4724 Graceful restart, then the > modifications of FSM restricted the collision detection from > RFC 4271 6.8.: >=20 > However, if the Graceful Restart Capability with one or more > AFIs/SAFIs has been received for the session, then in response > to Event 16 or Event 17 the local system: > ... > - drops the TCP connection associated with the ESTABLISHED > ... >=20 > If BGP speakers R1 and R2 simultaneously tries to establish BGP sessions > and the first connection advanced to Established state before the second > connection set up the TCP connection, then the situation depends on how > R1 and R2 are configured: >=20 > 1) If both R1 and R2 do not support RFC 4724, then the second connection > is ditched by collision detection. >=20 > 2) If both R1 and R2 have fully active graceful restart, then the > collision is handled as if both speakers restarted, first connection is > ditched as mentioned above and the second advances to established. >=20 > 3) But if both R1 and R2 support graceful restart, but R1 is configured > as receiver-only, then R1 closes the first connection (according to RFC > 4724), but R2 simultaneously closes the second connection (because R1 > announces graceful restart capability without any AFI/SAFI, therefore > modifications of FSM from RFC 4724 do not apply). After that both > speakers realise that the other connection is also down and after some > timeout they would try to reestablish the session, perhaps with the same > result. >=20 > Is such problem possible, or i am misinterpreting RFC 4724? >=20 > --=20 > Ondrej 'SanTiago' Zajicek > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Thu Feb 13 10:54:13 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782C81A0402 for ; Thu, 13 Feb 2014 10:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnkZznkxJE6B for ; Thu, 13 Feb 2014 10:54:01 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA001A03FC for ; Thu, 13 Feb 2014 10:54:01 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0Y00IOZ75ZIP@tid.hi.inet> for idr@ietf.org; Thu, 13 Feb 2014 19:53:59 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id B5.CB.03314.7C41DF25; Thu, 13 Feb 2014 19:53:59 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0Y00IOW75ZIP@tid.hi.inet> for idr@ietf.org; Thu, 13 Feb 2014 19:53:59 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.201]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 19:53:58 +0100 Date: Thu, 13 Feb 2014 18:53:57 +0000 From: Victor Lopez In-reply-to: X-Originating-IP: [10.95.64.115] To: Idr Message-id: Content-id: <6DFC4FA93633A1488E879124E5C7FE9D@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: New Version Notification for draft-lopez-pce-hpce-ted-01.txt Thread-index: AQHPKCzWusNPig0OzUaWZ7HCGfboG5qzWnyAgAAvDgA= user-agent: Microsoft-MacOutlook/14.3.9.131030 X-AuditID: 0a5f4068-b7fe58e000000cf2-a1-52fd14c732c3 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42Lhinfg0j0u8jfIYMlEQYtXt58xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+2U60wFX6QrFs1Zx9zAeFSsi5GTQ0LAROLqqdMsELaYxIV7 69lAbCGBA4wSd//6dTFyAdlfGSW+fV/DDuFsZJTobvnMDFLFIqAq8WvpIjCbTUBJYsO2PWDd wgKeEut+dzCC2JwC2hLvT8xngtigIPHn3GOwbSJA2z6sbQWL8wpoSbR9bwfrZRYwk1h28Qgj RFxQ4sfkeywQcR2J3u/fmCFscYk5vyayQtjaEk/eXQCzGQVkJVaeP80IMd9L4sbRdcwQtpXE 8fmz2UFsUQE9iXuP5kJ9LCCxZM95ZghbVOLl43+sEN8nSRw8fZx5AqPELCQnzUJy0iwkJ81C ctIsJCctYGRdxShWnFSUmZ5RkpuYmZNuYKiXkamXmZdasokREncZOxiX71Q5xCjAwajEw+vx 4E+QEGtiWXFl7iFGCQ5mJRHe6n9AId6UxMqq1KL8+KLSnNTiQ4xMHJxSDYx9gtM6/BkWenMt UPku9V3gltDpn+FhcnuO1B+Ks4l7486qHn+e1/h++M7MTol/R04bBbQnCd30D+sz/6ds/efz Nt/Y/qDoz3uvsIu9uRmRsXzb+mdvJQWtXwicVitu6v3O8Itjtvn2qQ4Pf3+Pv7Bq2myr7U6n JlSJvflQnc95cvvBrsZntu+VWIozEg21mIuKEwF4zEvEmQIAAA== References: <20140212195836.25824.39777.idtracker@ietfa.amsl.com> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/0RxnePznhwoH3mUzlt33tPb-Gy8 Subject: [Idr] FW: New Version Notification for draft-lopez-pce-hpce-ted-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:54:10 -0000 Dear all, We submitted a first version of this draft to the PCE WG. The PCE WG Proposed us to distribute the draft in the IDR mailing list because it presents an architecture to use BGP-LS in a Hierarchical PCE (H-PCE) scenario [RFC6805 - http://tools.ietf.org/html/rfc6805]. Just to give some background about the architecture. In H-PCE scenarios, there is a parent PCE and some child PCEs. The parent PCE does not have information of the whole network, but is only aware of the connectivity among the domains and provide coordination to the child PCEs. When there is a path request, it is sent to the parent PCE, which selects a set of candidate domain paths and sends requests to the child PCEs responsible for these domains. Then the parent PCE selects the best path. However, it is not defined how the parent PCE retrieves the information of the children PCEs. This draft presents how BGP-LS can be used in H-PCE scenarios to exchange information among the PCEs. This is an informational draft with the aim of explaining how both protocols can fit in the H-PCE architecture. Comments are welcome Victor, Oscar, Dan and Stefano >El 12/02/14 20:58, "internet-drafts@ietf.org" >escribi=F3: > >> >>A new version of I-D, draft-lopez-pce-hpce-ted-01.txt >>has been successfully submitted by Victor Lopez and posted to the >>IETF repository. >> >>Name: draft-lopez-pce-hpce-ted >>Revision: 01 >>Title: Traffic Engineering Database dissemination for Hier= archical PCE >>scenarios >>Document date: 2014-02-11 >>Group: Individual Submission >>Pages: 11 >>URL: >>http://www.ietf.org/internet-drafts/draft-lopez-pce-hpce-ted-01.txt >>Status: >>https://datatracker.ietf.org/doc/draft-lopez-pce-hpce-ted/ >>Htmlized: http://tools.ietf.org/html/draft-lopez-pce-hpce-ted-01 >>Diff: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-lopez-pce-hpce-ted-01 >> >>Abstract: >> The PCE architecture is well-defined and may be used to compute the >> optimal path for LSPS across domains in MPLS-TE and GMPLS networks. >> The Hierarchical Path Computation Element (H-PCE) [RFC6805] was >> developed to provide an optimal path when the sequence of domains is >> not known in advance. The procedure and mechanism for populating the >> Traffic Engineering Database (TED) with domain topology and link >> information used in H-PCE-based path computations is open to >> interpretation. This informational document describes how topology >> dissemination mechanisms may be used to provide TE information >> between Parent and Child PCEs (within the H-PCE context). In >> particular, it describes how BGP-LS might be used to provide inter- >> domain connectivity. This document is not intended to define new >> extensions, it demonstrates how existing procedures and mechanisms >> may be used. >> >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>The IETF Secretariat >> > ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From nobody Thu Feb 13 10:57:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBDB1A03EC for ; Thu, 13 Feb 2014 10:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiECuxYhEDKf for ; Thu, 13 Feb 2014 10:57:42 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id AC3E11A0350 for ; Thu, 13 Feb 2014 10:57:42 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Thu, 13 Feb 2014 13:57:36 -0500 Message-ID: <011601cf28ed$75e277d0$61a76770$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0117_01CF28C3.8D126340" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8o7TwqWxAjnhe6SZq+yjhL+Iil1g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/uiTrlnJEM2k1pLLmm3VLsgnMJdI Cc: "'John G. Scudder'" Subject: [Idr] draft-ietf-idr-bgp-enhanced-route-refresh-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:57:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0117_01CF28C3.8D126340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The ietf-idr-bgp-enhanced-route-refresh has passed the WG LC, and will be forwarded to the IESG for publication. Thank you for the active discussion on the draft. Sue ------=_NextPart_000_0117_01CF28C3.8D126340 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The = ietf-idr-bgp-enhanced-route-refresh has passed the WG LC, and will be = forwarded to the IESG for publication.

 

Thank you = for the active discussion on the draft.

 

 

Sue =

 

 

------=_NextPart_000_0117_01CF28C3.8D126340-- From nobody Thu Feb 13 11:11:42 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2791A0424 for ; Thu, 13 Feb 2014 11:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUrI8XyNoe8K for ; Thu, 13 Feb 2014 11:11:39 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFD61A0421 for ; Thu, 13 Feb 2014 11:11:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "idr wg" Date: Thu, 13 Feb 2014 14:11:28 -0500 Message-ID: <014801cf28ef$662ec670$328c5350$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0149_01CF28C5.7D5933A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8o7kVdJUECvJeXTk217FB354k4iA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HqFElaZvGHVzhcaBWFpStqRgOYw Cc: draft-ietf-idr-enhanced-refresh-impl@tools.ietf.org, "'John G. Scudder'" Subject: [Idr] draft-ietf-idr-enhanced-refresh-impl-00 - WG LC X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:11:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0149_01CF28C5.7D5933A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is a 1 week WG LC on the implementation draft: The draft-ietf-idr-enhanced-refresh-impl-00 Please include in your comments; Support: yes/no I know of IPR: yes/no The draft-ietf-idr-enhanced-route-refresh-06 has passed WG LC. Sue Hares and John Scudder ------=_NextPart_000_0149_01CF28C5.7D5933A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a = 1 week WG LC on the implementation draft:

 

The = draft-ietf-idr-enhanced-refresh-impl-00

 

Please = include in your comments;

Support: = yes/no

I know of IPR: yes/no  =  

 

The draft-ietf-idr-enhanced-route-refresh-06 has = passed WG LC.

 

Sue Hares = and John Scudder

 

------=_NextPart_000_0149_01CF28C5.7D5933A0-- From nobody Thu Feb 13 13:01:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1E51A04D8 for ; Thu, 13 Feb 2014 13:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FplnfjcwAdGH for ; Thu, 13 Feb 2014 13:01:37 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A1EE11A0470 for ; Thu, 13 Feb 2014 13:01:37 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 43EE7C2F1; Thu, 13 Feb 2014 16:01:36 -0500 (EST) Date: Thu, 13 Feb 2014 16:01:36 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20140213210136.GI31462@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/g_5O1TRXkaklUwdcXIDJidoFk-k Subject: [Idr] [internet-drafts@ietf.org: I-D Action: draft-raszuk-wide-bgp-communities-04.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:01:39 -0000 We have published an updated version of the Wide BGP Communities draft and would like to invite your review. The eventual goal is IDR WG adoption. -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- Date: Thu, 13 Feb 2014 12:55:54 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-raszuk-wide-bgp-communities-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Wide BGP Communities Attribute Authors : Robert Raszuk Jeffrey Haas Andrew Lange Shane Amante Bruno Decraene Paul Jakma Richard A Steenbergen Filename : draft-raszuk-wide-bgp-communities-04.txt Pages : 24 Date : 2014-02-13 Abstract: Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a very common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. Such information is important to allow BGP speakers to perform some mutually agreed actions without the need to maintain a separate offline database for each tuple of prefix and associated set of action entries. This document defines a new encoding which will enhance and simplify what can be accomplished today with the use of BGP communities. The most important addition this specification makes over currently defined BGP communities is the ability to specify, carry as well as use for execution an operator's defined set of parameters. It also provides an extensible platform for any new community encoding needs in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-raszuk-wide-bgp-communities/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-raszuk-wide-bgp-communities-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-raszuk-wide-bgp-communities-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- From nobody Thu Feb 13 13:56:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099531A0124; Thu, 13 Feb 2014 13:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv75ZAsg3ruY; Thu, 13 Feb 2014 13:56:09 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 64FDF1A0215; Thu, 13 Feb 2014 13:56:09 -0800 (PST) Received: from mail134-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE009.bigfish.com (10.236.130.72) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 21:56:08 +0000 Received: from mail134-co9 (localhost [127.0.0.1]) by mail134-co9-R.bigfish.com (Postfix) with ESMTP id D06FC2A0276; Thu, 13 Feb 2014 21:56:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.16; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371IfecIc85eh148cI1432I1415I11fbIzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1082kzz1de098h1033IL8275bh8275dh1de097h186068hz31h2a8h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2bh1b2fh1bceh224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3h20f0h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24ach24d7h2516h2545h255eh1155h) Received-SPF: softfail (mail134-co9: transitioning domain of juniper.net does not designate 66.129.239.16 as permitted sender) client-ip=66.129.239.16; envelope-from=jgs@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail134-co9 (localhost.localdomain [127.0.0.1]) by mail134-co9 (MessageSwitch) id 1392328566379122_30607; Thu, 13 Feb 2014 21:56:06 +0000 (UTC) Received: from CO9EHSMHS031.bigfish.com (unknown [10.236.132.236]) by mail134-co9.bigfish.com (Postfix) with ESMTP id 4790BE0048; Thu, 13 Feb 2014 21:56:06 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by CO9EHSMHS031.bigfish.com (10.236.130.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 21:56:04 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 13 Feb 2014 13:56:03 -0800 Received: from jgs-sslvpn-nc.jnpr.net (jgs-sslvpn-nc.jnpr.net [172.29.37.30]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s1DLtlL46936; Thu, 13 Feb 2014 13:55:55 -0800 (PST) (envelope-from jgs@juniper.net) Content-Type: multipart/alternative; boundary="Apple-Mail=_2BA14792-C15E-4A78-85C3-A772AD059B8C" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "John G. Scudder" In-Reply-To: <18BC300A-44BC-4847-8A55-BBB8AD48050A@exa-networks.co.uk> Date: Thu, 13 Feb 2014 16:56:02 -0500 Message-ID: References: <001b01cf27b8$66ebd130$34c37390$@ndzh.com> <8312D4C0-E3AC-4E9B-9330-4D4708FCB6D7@exa-networks.co.uk> <00a301cf280d$3a1da160$ae58e420$@ndzh.com> <18BC300A-44BC-4847-8A55-BBB8AD48050A@exa-networks.co.uk> To: Thomas Mangin X-Mailer: Apple Mail (2.1827) X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/idr/a0omaYSqYLfQ0B1-4P40FAuoNog Cc: "idr@ietf. org" , "" , Hares Susan Subject: Re: [Idr] Call for presentations for IETF X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:56:13 -0000 --Apple-Mail=_2BA14792-C15E-4A78-85C3-A772AD059B8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" I agree that it'd be a generally nice and orderly thing to have = consistent TLV usage going forward. I think any notion of going back and = changing existing practice (including for specs still in draft but = fairly mature, especially in terms of implementation) is wildly = optimistic to say the least. Thanks for bringing this up and I look forward to more discussion of it. $0.02, --John On Feb 12, 2014, at 11:49 AM, Thomas Mangin = wrote: > Hello Susan, >=20 > Thank you for your help. >=20 > This is not an hot topic, BGP can live with disparate TLV format .. It = just seems ... messy to me :-) >=20 > I fear I will not have time to write my first draft for London but if = enough think it is worth some discussion time, I will find a way to make = it happen .. I just believe I may just regret this statement :-) >=20 > Otherwise I am happy to speak about it informally, all what is needed = is "rough consensus" of the current draft writer to update their = document the same way :-) >=20 > I agree that AIGP is now way too far down the line for changes ... I = listed it as it is using a TLV format ...=20 > But it may not be the same for all others drafts :-) >=20 > Thomas >=20 > On 12 Feb 2014, at 16:12, Susan Hares wrote: >=20 >> Thomas: >> =20 >> You are welcome to discuss these issues on the list. I will bring = up your concern during my summary slide of the drafts. >> =20 >> The reason for drafts is that so people can see your pros-cons prior = to the meeting. Or if they remote, understand your points clearly. = Many BGP drafts are often 1 or 2 pages of text surrounded by boiler = plate. You could even name it =93mangin-1-TLV-Please=94. =20 >> =20 >> AIGP did a have two series of WG last calls and was approved. It has = 3+ implementations. I am still crafting the shepherds report this = weekend (after IETF drafts close), so the list discussion is helpful. >> =20 >> Sue >> =20 >> From: Thomas Mangin [mailto:thomas.mangin@exa-networks.co.uk]=20 >> Sent: Wednesday, February 12, 2014 4:42 AM >> To: idr-bounces@ietf.org >> Cc: idr wg; John G. Scudder; Susan Hares >> Subject: Re: [Idr] Call for presentations for IETF >> =20 >> Even for things like :=20 >> =20 >> There is currently 4 (from memory) different draft requiring and = proposing different, incompatible implementations of a TLV format in = BGP. >> Could some effort be put together to define ONE TLV format, so = implementations do not need to include 4/5 different ones. >> Could some minor changes be done to last call draft to make their = format compatible with grand generalised TLV format. >> =20 >> People may wonder which draft ? :-) >> - draft-ietf-idr-aigp-10 >> - draft-frs-bgp-operational-message-00 >> - draft-raszuk-wide-bgp-communities-03 >> - And there is surely some more ... >> =20 >> Having discussed it quickly with one of the author of the draft = above, the quick overview seems to be : >> - operational =3D True TLV >> - aigp =3D almost like operational, but only a single octet for the = type >> - widecomm =3D Really, TV , no length, and part of the extcommunity = specification >> =20 >> So it would seems that with minor modifications, it could be = possible. >> =20 >> Oh ! Sue, I know the answer is no, and it is great as no one want to = come to its first IETF to take the stage and argue with regular = attendant :-) >> But at least the question has been asked and hopefully will be = discussed :-) >> =20 >> Thomas >> =20 >> On 12 Feb 2014, at 06:05, Susan Hares wrote: >>=20 >>=20 >> Please let John and I know if you wish to make a presentation at ietf = 89. >> As always IDR meeting motto is =93no draft, no presentation=94. >> =20 >> IDR is on Thursday from 13:00-15:00 GMT. =20 >> =20 >> Just respond to this email to request your presentation slot. >> =20 >> Sue Hares >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 --Apple-Mail=_2BA14792-C15E-4A78-85C3-A772AD059B8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" I agree that it'd be a generally = nice and orderly thing to have consistent TLV usage going forward. I = think any notion of going back and changing existing practice (including = for specs still in draft but fairly mature, especially in terms of = implementation) is wildly optimistic to say the = least.

Thanks for bringing this up and I look forward = to more discussion of = it.

$0.02,

--John
<= div>
On Feb 12, 2014, at 11:49 AM, Thomas Mangin <thomas.mangin@exa-network= s.co.uk> wrote:

Hello = Susan,

Thank you for your = help.

This is not an hot topic, BGP can live = with disparate TLV format .. It just seems ... messy to me = :-)

I fear I will not have time to write my = first draft for London but if enough think it is worth some discussion = time, I will find a way to make it happen .. I just believe I may just = regret this statement :-)

Otherwise I am happy = to speak about it informally, all what is needed is "rough consensus" of = the current draft writer to update their document the same way = :-)

I agree that AIGP is now way too far down = the line for changes ...  I listed it as it is using a TLV format =  ... 
But it may not be the same for all others = drafts :-)

Thomas

On 12 = Feb 2014, at 16:12, Susan Hares <shares@ndzh.com> wrote:

Thomas:
 
You are welcome to = discuss these issues on the list.   I will bring up your = concern during my summary slide of the = drafts.
 
The reason for drafts is that so people can see your = pros-cons prior to the meeting. Or if they remote, understand your = points clearly.   Many BGP drafts  are often 1 or 2 pages = of text surrounded by boiler plate.  You could even name it  = =93mangin-1-TLV-Please=94.   
 
AIGP did a have two = series of WG last calls and was approved.  It has 3+ = implementations. I am still crafting the shepherds report this weekend = (after IETF drafts close), so the list discussion is = helpful.
 
Sue
 
From: Thomas Mangin [mailto:thomas.mangin@exa-= networks.co.uk] 
Sent: Wednesday, February 12, = 2014 4:42 AM
To: idr-bounces@ietf.org
Cc: idr wg; John G. = Scudder; Susan Hares
Subject: Re: [Idr] Call for = presentations for IETF
 
Even = for things like : 
 
There = is currently 4 (from memory) different draft requiring and proposing = different, incompatible implementations of a TLV format in = BGP.
Could some = effort be put together to define ONE TLV format, so implementations do = not need to include 4/5 different ones.
Could some minor changes be done to last call draft = to make their format compatible with grand generalised TLV = format.
 
People may wonder which draft ? = :-)
- = draft-ietf-idr-aigp-10
- draft-frs-bgp-operational-message-00
- = draft-raszuk-wide-bgp-communities-03
- And there is surely some more = ...
 
Having discussed it quickly with one of the author of the draft = above, the quick overview seems to be :
 - operational =3D True TLV
 - aigp =3D = almost like operational, but only a single octet for the type
 - = widecomm =3D Really, TV , no length, and part of the extcommunity = specification
 
So it = would seems that with minor modifications, it could be = possible.
 
Oh ! = Sue, I know the answer is no, and it is great as no one want to come to = its first IETF to take the stage and argue with regular attendant = :-)
But at least = the question has been asked and hopefully will be discussed = :-)
 
Thomas
 
On 12 = Feb 2014, at 06:05, Susan Hares <shares@ndzh.com> wrote:


Please let John and I know if you wish to make a = presentation at ietf 89.
As always IDR meeting motto is =93no draft, no = presentation=94.
 
IDR is on Thursday from 13:00-15:00 GMT.  =  
 
Just respond to this email to request your = presentation slot.
 
Sue Hares
_______________________________________________
Idr = mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
=


= --Apple-Mail=_2BA14792-C15E-4A78-85C3-A772AD059B8C-- From wwwrun@rfc-editor.org Wed Feb 12 19:39:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167121A00AF for ; Wed, 12 Feb 2014 19:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JexVPD9mMqMm for ; Wed, 12 Feb 2014 19:39:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id EFC621A00AB for ; Wed, 12 Feb 2014 19:39:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 115107FC177; Wed, 12 Feb 2014 19:39:56 -0800 (PST) To: pst@cisco.com, rchandra@cisco.com, tli@skat.usc.edu, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20140213033956.115107FC177@rfc-editor.org> Date: Wed, 12 Feb 2014 19:39:56 -0800 (PST) X-Mailman-Approved-At: Thu, 13 Feb 2014 13:58:10 -0800 Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC1997 (3889) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 03:39:59 -0000 The following errata report has been submitted for RFC1997, "BGP Communities Attribute". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=1997&eid=3889 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 3 Original Text ------------- " This document creates the COMMUNITIES path attribute is an optional transitive attribute of variable length. The attribute consists of a set of four octet values, each of which specify a community. All routes with this attribute belong to the communities listed in the attribute." Corrected Text -------------- " This document creates the COMMUNITIES path attribute, which is an optional transitive attribute of variable length. The attribute consists of a set of four octet values, each of which specify a community. All routes with this attribute belong to the communities listed in the attribute." Notes ----- Typo in first sentence. "which" is missing. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC1997 (no draft string recorded) -------------------------------------- Title : BGP Communities Attribute Publication Date : August 1996 Author(s) : R. Chandra, P. Traina, T. Li Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Feb 13 15:28:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0128B1A0037 for ; Thu, 13 Feb 2014 15:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfhuhzvkN_70 for ; Thu, 13 Feb 2014 15:28:42 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id CB3941A0023 for ; Thu, 13 Feb 2014 15:28:42 -0800 (PST) Received: from mail134-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 23:28:41 +0000 Received: from mail134-co1 (localhost [127.0.0.1]) by mail134-co1-R.bigfish.com (Postfix) with ESMTP id 3848680318; Thu, 13 Feb 2014 23:28:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0511HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz98dIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail134-co1: domain of juniper.net designates 157.56.245.197 as permitted sender) client-ip=157.56.245.197; envelope-from=hannes@juniper.net; helo=CH1PRD0511HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail134-co1 (localhost.localdomain [127.0.0.1]) by mail134-co1 (MessageSwitch) id 1392334119125080_26639; Thu, 13 Feb 2014 23:28:39 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.233]) by mail134-co1.bigfish.com (Postfix) with ESMTP id 1B4458C004B; Thu, 13 Feb 2014 23:28:39 +0000 (UTC) Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 23:28:38 +0000 Received: from juniper.net (193.110.55.16) by pod51010.outlook.com (10.255.159.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Thu, 13 Feb 2014 23:28:37 +0000 Date: Fri, 14 Feb 2014 00:28:32 +0100 From: Hannes Gredler To: Ondrej Zajicek Message-ID: <20140213232832.GD3701@juniper.net> References: <20140213160647.GZ13804@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20140213160647.GZ13804@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.55.16] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/idr/_5Yugp9eBVewHn6hrGtTcfKUvbo Cc: idr@ietf.org Subject: Re: [Idr] Possible problem in RFC 4724 Graceful restart? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:28:45 -0000 On Thu, Feb 13, 2014 at 05:06:47PM +0100, Ondrej Zajicek wrote: | Hi | | If i understand correctly RFC 4724 Graceful restart, then the | modifications of FSM restricted the collision detection from | RFC 4271 6.8.: | | However, if the Graceful Restart Capability with one or more | AFIs/SAFIs has been received for the session, then in response | to Event 16 or Event 17 the local system: | ... | - drops the TCP connection associated with the ESTABLISHED | ... | | If BGP speakers R1 and R2 simultaneously tries to establish BGP sessions | and the first connection advanced to Established state before the second | connection set up the TCP connection, then the situation depends on how | R1 and R2 are configured: | | 1) If both R1 and R2 do not support RFC 4724, then the second connection | is ditched by collision detection. | | 2) If both R1 and R2 have fully active graceful restart, then the | collision is handled as if both speakers restarted, first connection is | ditched as mentioned above and the second advances to established. | | 3) But if both R1 and R2 support graceful restart, but R1 is configured | as receiver-only, then R1 closes the first connection (according to RFC | 4724), but R2 simultaneously closes the second connection (because R1 | announces graceful restart capability without any AFI/SAFI, therefore | modifications of FSM from RFC 4724 do not apply). After that both | speakers realise that the other connection is also down and after some | timeout they would try to reestablish the session, perhaps with the same | result. | | Is such problem possible, or i am misinterpreting RFC 4724? in theory yes, practially speaking BGP implementations have a reconnect timer which gets jittered a bit, such that on subsequent bringup attempts, colissions are less likely. HTH, /hannes From nobody Thu Feb 13 15:40:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DF51A04E3 for ; Thu, 13 Feb 2014 15:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QI5xTYiFDuq for ; Thu, 13 Feb 2014 15:40:29 -0800 (PST) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA021A02E3 for ; Thu, 13 Feb 2014 15:40:29 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.95,841,1384318800"; d="scan'208";a="61742587" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 Feb 2014 18:38:42 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 13 Feb 2014 18:40:27 -0500 From: "George, Wes" To: "UTTARO, JAMES" , Christopher Morrow Date: Thu, 13 Feb 2014 18:40:25 -0500 Thread-Topic: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt Thread-Index: Ac8pFPi3PkAN/DWfRtiHWXN72hWtAg== Message-ID: References: <-4042749855639388205@gmail297201516> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/E5uKtZ4dHNO9_glRELm3Dhj6OOQ Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:40:32 -0000 SmFtZXMgLQ0KDQpJIHdhcyBkb2luZyBzb21lIHJlYWRpbmcgYWJvdXQgQVNfT1ZFUlJJREUgaW4g cHJlcGFyYXRpb24gdG8gdHJ5IHRvDQppbmNvcnBvcmF0ZSB5b3VyIGNvbW1lbnRzIGludG8gdGhl IGRyYWZ0LCBhbmQgSeKAmW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kDQpob3cgdGhpcyBpcyByZWxh dGVkIHRvIEFTIG1pZ3JhdGlvbiwgd2hpY2ggaXMgd2hhdCB0aGlzIGRyYWZ0IGRpc2N1c3Nlcy4N CldoaWxlIHRoZXJlIG1heSBiZSBhZGRpdGlvbmFsIEJHUCBNYW5pcHVsYXRpb24gY2FzZXMgdGhh dCBhcmUNCnZlbmRvci1zcGVjaWZpYyBhbmQgbmVlZCB0byBiZSBkb2N1bWVudGVkLCB0aGlzIG1h eSBub3QgYmUgdGhlIHJpZ2h0IGZpdA0KZm9yIHRoaXMgc3BlY2lmaWMgZHJhZnQsIGVzcGVjaWFs bHkgc2luY2UgdGhpcyBkcmFmdCBvcmlnaW5hdGVkIGZyb20gdGhlDQpmYWN0IHRoYXQgd2UgbmVl ZGVkIHRvIGRvY3VtZW50IHNvbWV0aGluZyB0aGF0IGlzIHRvZGF5IHVub2ZmaWNpYWxseSB1c2Vk DQppbiBCR1AgaW4gb3JkZXIgdG8gcHJldmVudCBTSURS4oCZcyBwYXRoIHZhbGlkYXRpb24gZnJv bSBicmVha2luZyB0aGUNCnByb2Nlc3MuIFNpbmNlIFNJRFIgaXMgbm90IHVzZWQgaW4gVlBOIG5l dHdvcmtzIGF0IGFsbCwgd2UgZGlkbuKAmXQgc2VlIHRoYXQNCmFzIG92ZXJseSBuZWNlc3Nhcnks IGF0IGxlYXN0IHJpZ2h0IG5vdy4NCg0KQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KVGhhbmtz LA0KDQpXZXMNCg0KDQoNCg0KT24gMS8xOC8xNCwgMTI6NTAgUE0sICJVVFRBUk8sIEpBTUVTIiA8 anUxNzM4QGF0dC5jb20+IHdyb3RlOg0KDQo+SXQgd291bGQgc2VlbSB0byBtZSB0aGF0IHRoaXMg aXMgcHJpbWFyaWx5IGluZm9ybWF0aW9uYWwgaW4gbmF0dXJlLiBUaGVyZQ0KPmFyZSBvdGhlciBt ZXRob2RzIG9mIG1hbmlwdWxhdGluZyBBUy1QQVRIIGkuZSBBU19PVkVSUklERSB0aGF0IGFyZSB1 c2VkLg0KPkFzIHRoZXNlIHRvb2xzIGFyZSBhbHNvIHVzZWQgaW4gb3RoZXIgc3BhY2VzIGkuZSBW UE4gaXQgd291bGQgc2VlbQ0KPnBydWRlbnQgdG8gaW5jbHVkZSBvdGhlciB1c2UgY2FzZXMuLiBP bmUgaXMgdGhlIGFiaWxpdHkgdG8gaGF2ZSBtdWx0aXBsZQ0KPmN1c3RvbWVyIGVuZHBvaW50cyB1 c2luZyB0aGUgc2FtZSBBUyB0byBjb21tdW5pY2F0ZSBvdmVyIHRoZSBTUHMgbmV0d29yay4NCj5J biB0aGlzIGNhc2UgYW4gYXBwcm9hY2ggbWF5IGJlIHRvIHVzZSBBU19PVkVSUklERSB0byBkaXNh YmxlIHRoZSBBU19QQVRIDQo+bG9vcCBwcmV2ZW50aW9uIG1ldGhvZC4uDQoNCg0KVGhpcyBFLW1h aWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2Fi bGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVu dGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENh YmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBv ciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2ht ZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5s YXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUg b3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Thu Feb 13 22:51:42 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0143A1A00C5; Thu, 13 Feb 2014 22:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuC2C2EGFuj0; Thu, 13 Feb 2014 22:51:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE5F1A0111; Thu, 13 Feb 2014 22:51:38 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WECcZ-0000cq-Mk; Fri, 14 Feb 2014 06:51:36 +0000 Date: Fri, 14 Feb 2014 15:51:34 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/5ncyTTcNfaxr8TQKE6-BLbmICBE Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 06:51:40 -0000 > http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id > "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, > 2014-02-12 please no. if you can not assign a unique four octet integer to each router in your network, then you have much bigger problems. and adding a capability and more complexity to try to patch over your inability to configure your routers will just compound your problems. randy From nobody Fri Feb 14 01:06:08 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0841A01EA; Fri, 14 Feb 2014 01:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMpiw22HdVKX; Fri, 14 Feb 2014 01:05:51 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id B81AD1A011E; Fri, 14 Feb 2014 01:05:50 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so8984619lbi.21 for ; Fri, 14 Feb 2014 01:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hXWYXiHxf5Rj3TRsYdaJkYsQPpWJIth5C23uVS+aR4U=; b=OxiGYeknqEnKEFBShxgNFllSUoJ3ilWua1YwfAq8zq0dpkcKjzh12s6zTOctZV37wL lnXo9wDEP4yOtE3WFRKr7AObXHOmK8/uqj1rkBojCrO9DplsUZnBn8uY6X4+vTrLlt3X Rc5sBLbO4r7SKmcT+1kQ33PcXj9Eu9WEshnk4SXPt7e9QuA2IwMOV2OG7W+yDCnO/Gcy Kp7SPjEGttcJEpH6YszHU40WLsfKa5nV5SfwHk1l7+a+i8ejDqUZrwUkOWMjFEJnQSOb 7YWCEDbjMJn98NJmuV1EmvSCvWdNU0jY9ZDZufZ3tbifzJmBW6qz/AiHCyFiLtY8coeb 6vTQ== MIME-Version: 1.0 X-Received: by 10.112.172.8 with SMTP id ay8mr1333531lbc.41.1392368748481; Fri, 14 Feb 2014 01:05:48 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.51.105 with HTTP; Fri, 14 Feb 2014 01:05:48 -0800 (PST) In-Reply-To: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> Date: Fri, 14 Feb 2014 10:05:48 +0100 X-Google-Sender-Auth: 11kLKKNItesOtjQrTGQJuEnGBlo Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: multipart/alternative; boundary=001a11c2b3f0a651e304f25a1c03 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ApfI3a2oLd3Hu-yG2RSUJLgUnTY Cc: idr wg , V6 Ops List , Fred Baker Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 09:05:53 -0000 --001a11c2b3f0a651e304f25a1c03 Content-Type: text/plain; charset=ISO-8859-1 I agree with Randy'a point here. BGP rtr_id does not need to be a routable address - it just needs to be unique 32 bits within the domain scope. We have had this discussion already during RFC6286 and concluded that 4 octet is sufficient for any type of BGP mesh. If anything I would propose to go opposite and to ask your implementation to allow UTF-8 encoded BGP rtr_id format. Rgs, R. On Fri, Feb 14, 2014 at 7:51 AM, Randy Bush wrote: > > http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id > > "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, > > 2014-02-12 > > please no. if you can not assign a unique four octet integer to each > router in your network, then you have much bigger problems. and adding > a capability and more complexity to try to patch over your inability to > configure your routers will just compound your problems. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a11c2b3f0a651e304f25a1c03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with Randy'a point here.=A0

BGP rtr_id does not need to be a routable address -= it just needs to be unique 32 bits within the domain scope.=A0

We have had this discussion already during RFC6286 = and concluded that 4 octet is sufficient for any type of BGP mesh.=A0
=

If anything I would propose to go opposite and to a= sk your implementation to allow UTF-8 encoded BGP rtr_id format.=A0

Rgs,
R.

On Fri, Feb 14, 2014 at 7:51 AM, Randy Bus= h <= randy@psg.com> wrote:
> http://tools.ie= tf.org/html/draft-fan-idr-ipv6-bgp-id
> =A0 "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zh= enqiang Li,
> =A0 2014-02-12

please no. =A0if you can not assign a unique four octet integer to ea= ch
router in your network, then you have much bigger problems. =A0and adding a capability and more complexity to try to patch over your inability to
configure your routers will just compound your problems.

randy

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

--001a11c2b3f0a651e304f25a1c03-- From nobody Fri Feb 14 06:01:30 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55ED1A0262 for ; Fri, 14 Feb 2014 06:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQvv2FK4asfS for ; Fri, 14 Feb 2014 06:01:16 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 700301A0250 for ; Fri, 14 Feb 2014 06:01:16 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'UTTARO, JAMES'" , "'George, Wes'" , "'Christopher Morrow'" References: <-4042749855639388205@gmail297201516> In-Reply-To: Date: Fri, 14 Feb 2014 09:01:06 -0500 Message-ID: <002b01cf298d$34dfbf40$9e9f3dc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHKcwyD3YKaa8Hbdmi5Lms+hIEcOAH3DiaWAmaMsz0CD9rBNQFO51jsAklF5QqabgahcA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/idr/7EDjhmv0HtvHeidi2shAyBGZmIA Cc: 'idr wg' , 'Robert Raszuk' Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:01:20 -0000 This draft has been accepted by the IDR WG. Will the authors please = submit this as:=20 Draft-ietf-idr-migration-01.txt The Grow co-chair (Chris Marrow) will serve as the document shepherd.=20 Sue=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of UTTARO, JAMES Sent: Saturday, January 18, 2014 12:51 PM To: George, Wes; Christopher Morrow Cc: idr wg; Robert Raszuk Subject: Re: [Idr] Question about draft: = draft-ga-idr-as-migration-03.txt It would seem to me that this is primarily informational in nature. = There are other methods of manipulating AS-PATH i.e AS_OVERRIDE that are = used. As these tools are also used in other spaces i.e VPN it would seem = prudent to include other use cases.. One is the ability to have multiple = customer endpoints using the same AS to communicate over the SPs = network. In this case an approach may be to use AS_OVERRIDE to disable = the AS_PATH loop prevention method.. =20 Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of George, Wes Sent: Wednesday, January 15, 2014 10:08 AM To: Christopher Morrow Cc: idr wg; Robert Raszuk Subject: Re: [Idr] Question about draft: = draft-ga-idr-as-migration-03.txt Thought I should maybe weigh in as an author... >>> Well this draft discusses applicability of local-as, no-prepend and=20 >>> replace-as knobs. I >> >> right, vendor specific configuration options, not changes to the bgp=20 >> protocol itself... I thought. >> The stated goal is to codify this behavior as a standard so that it is = clear that future changes to BGP must either support this function or = explicitly gain consensus to deprecate/break it. >> >>> IMO it does belong to IDR as implementations first need to support=20 >>> such knobs in order for operators to discuss its use in GROW. And=20 >>> for that implementors need to understand them. While 3 quoted=20 >>> implementations support it (better or worse :) there are number of=20 >>> other BGP code basis which still do not. >> >> wait, so now IDR is going to spec implementation knobs? that seems=20 >>like it's outside of the charter to me... or rather I don't see this=20 >>in the list of work items or in the generic charter fluff before work = >>items. >> >> it seems much more clearly to fit in the grow world view... (not that = >> I want more work in grow, but this just doesn't seem like IDR to This is a little hinky as =E2=80=9Cprotocol work=E2=80=9D because = it=E2=80=99s local only, rather than something that requires interop = between BGP speakers at an implementation level, but as noted, SIDR was = about to introduce protocol changes that would have broken it. In = putting this draft into IDR, I=E2=80=99m going by the recommendations = from the folks involved in SIDR (of which the IDR overlap is nonzero) = that in order to expect SIDR to change the BGPSec design for something = that is heavily used but not technically part of the BGP Spec, it really = should be standardized first, and IDR is where BGP protocol work is = done. Hence the dependent normative reference between = draft-ietf-sidr-as-migration and this draft. I=E2=80=99m open to putting it in GROW if that=E2=80=99s where it makes = more sense, just need some solid direction one way or the other. Thanks Wes George Anything below this line has been added by my company=E2=80=99s mail = server, I have no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Fri Feb 14 06:03:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ACF1A025E; Fri, 14 Feb 2014 06:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APPOw-oro3hH; Fri, 14 Feb 2014 06:03:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 886591A0250; Fri, 14 Feb 2014 06:03:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214140317.6411.93730.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 06:03:17 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ZhjSACdVh8fRXNLXsN5Wb-g3eq0 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-migration-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:03:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute Authors : Wesley George Shane Amante Filename : draft-ietf-idr-as-migration-00.txt Pages : 14 Date : 2014-02-14 Abstract: This draft discusses common methods of managing an ASN migration using some BGP feaures that while commonly-used are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work such as BGPSec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-migration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as-migration-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 06:26:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B29E1A0267 for ; Fri, 14 Feb 2014 06:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfYDnIjtvBXF for ; Fri, 14 Feb 2014 06:26:13 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id F2FC21A0283 for ; Fri, 14 Feb 2014 06:26:11 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 2872ef25.2ae383c05940.86939.00-2455.245193.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 14 Feb 2014 14:26:10 +0000 (UTC) X-MXL-Hash: 52fe278221af582e-d3df778430f1ecf81e2905be160168a42cb10e53 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 0872ef25.0.86914.00-2394.245049.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 14 Feb 2014 14:26:09 +0000 (UTC) X-MXL-Hash: 52fe27812998ebf6-4db7a22d336a44987d00acd69e957c5ea30a9f84 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1EEQ779006795; Fri, 14 Feb 2014 09:26:08 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1EEQ2mv006653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Feb 2014 09:26:05 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 14 Feb 2014 14:25:46 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0174.001; Fri, 14 Feb 2014 09:25:45 -0500 From: "UTTARO, JAMES" To: "George, Wes" , Christopher Morrow Thread-Topic: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt Thread-Index: Ac8SA40e7qKZlxliRMOMDETCRyUg8gCccYbgBTJjWYAAFD1zUA== Date: Fri, 14 Feb 2014 14:25:45 +0000 Message-ID: References: <-4042749855639388205@gmail297201516> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.92.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=EIuxJSlC c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=jHsTzGoMUScA:10 a=ofMgfj31e3cA:10 a=3uilPtFf00UA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=pVeHzU-_PH4A:10 a=ahv8dbORAAAA:8 a=WTAjMu4XX-lmye] X-AnalysisOut: [9nT9QA:9 a=QEXdDO2ut3YA:10 a=BDsChg1p1CEA:10 a=Hz7IrDYlS0c] X-AnalysisOut: [A:10 a=SYLDBP8qltzfQ2RU:21 a=d-AWVH5VSf2Ef8iK:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/A4WW8cb2e-NqyDz3L-8I1eCKe1E Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Question about draft: draft-ga-idr-as-migration-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:26:16 -0000 V2VzLA0KDQoJV2UgaGF2ZSBtdWx0aXBsZSBBUyBkb21haW5zIHRoYXQgaGF2ZSBiZWVuIGNyZWF0 ZWQgZm9yIHZhcmlvdXMgcmVhc29ucyB1bmRlciBvdXIgb3duIGFkbWluaXN0cmF0aXZlIGF1dGhv cml0eS4gV2UgaGF2ZSB1c2VkIGEgbnVtYmVyIG9mIHRoZSB0b29scyBtZW50aW9uZWQgaW4geW91 ciBkcmFmdCBidXQgYWxzbyB3ZSBoYXZlIHVzZSBBUy1PVkVSUklJREUgdG8gImFwcGVhciIgYXMg YSBkaWZmZXJlbnQgQVMgdG8gYW4gZUJHUCBwZWVyIHdpdGhpbiBvdXIgb3duIGFkbWluIGF1dGhv cml0eSBvciB3aXRoIGN1c3RvbWVycy4gIEkgdGhvdWdodCB0aGUgZHJhZnQgd2FzIHdpZGVyIGlu IHNjb3BlIGFuZCB3YXMgaW50ZW5kZWQgdG8gZG9jdW1lbnQgYW5kIHByb3ZpZGUgZ3VpZGFuY2Ug YXMgdG8gdGhlIHZhcmlvdXMgdmVuZG9yIHRvb2xzIGFuZCB0aGVyZSByYW1pZmljYXRpb25zIGlu IHRoZSBMM1ZQTiBjb250ZXh0LiBJZiBpdCBpcyBzcGVjaWZpYyB0byBvbmx5IElQVjQgdGhlbiBJ IGJlbGlldmUgaXQgaXMgbWlzc2luZyBvdXQgb24gYW4gb3Bwb3J0dW5pdHkgdG8gaWRlbnRpZnkg bXVsdGlwbGUgQVMgZG9tYWlucywgbWlncmF0aW9uIGV0Yy4uLiBhY3Jvc3MgTDJWUE4sIEwzVlBO LCBTRE4gQ29udHJvbGxlciAoIEZsb3dzcGVjICkgLi4uLiANCg0KSmltIFV0dGFybw0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogR2VvcmdlLCBXZXMgW21haWx0bzp3ZXNsZXku Z2VvcmdlQHR3Y2FibGUuY29tXSANClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCA2 OjQwIFBNDQpUbzogVVRUQVJPLCBKQU1FUzsgQ2hyaXN0b3BoZXIgTW9ycm93DQpDYzogaWRyIHdn OyBSb2JlcnQgUmFzenVrDQpTdWJqZWN0OiBSZTogW0lkcl0gUXVlc3Rpb24gYWJvdXQgZHJhZnQ6 IGRyYWZ0LWdhLWlkci1hcy1taWdyYXRpb24tMDMudHh0DQoNCkphbWVzIC0NCg0KSSB3YXMgZG9p bmcgc29tZSByZWFkaW5nIGFib3V0IEFTX09WRVJSSURFIGluIHByZXBhcmF0aW9uIHRvIHRyeSB0 bw0KaW5jb3Jwb3JhdGUgeW91ciBjb21tZW50cyBpbnRvIHRoZSBkcmFmdCwgYW5kIEnigJltIG5v dCBzdXJlIEkgdW5kZXJzdGFuZA0KaG93IHRoaXMgaXMgcmVsYXRlZCB0byBBUyBtaWdyYXRpb24s IHdoaWNoIGlzIHdoYXQgdGhpcyBkcmFmdCBkaXNjdXNzZXMuDQpXaGlsZSB0aGVyZSBtYXkgYmUg YWRkaXRpb25hbCBCR1AgTWFuaXB1bGF0aW9uIGNhc2VzIHRoYXQgYXJlDQp2ZW5kb3Itc3BlY2lm aWMgYW5kIG5lZWQgdG8gYmUgZG9jdW1lbnRlZCwgdGhpcyBtYXkgbm90IGJlIHRoZSByaWdodCBm aXQNCmZvciB0aGlzIHNwZWNpZmljIGRyYWZ0LCBlc3BlY2lhbGx5IHNpbmNlIHRoaXMgZHJhZnQg b3JpZ2luYXRlZCBmcm9tIHRoZQ0KZmFjdCB0aGF0IHdlIG5lZWRlZCB0byBkb2N1bWVudCBzb21l dGhpbmcgdGhhdCBpcyB0b2RheSB1bm9mZmljaWFsbHkgdXNlZA0KaW4gQkdQIGluIG9yZGVyIHRv IHByZXZlbnQgU0lEUuKAmXMgcGF0aCB2YWxpZGF0aW9uIGZyb20gYnJlYWtpbmcgdGhlDQpwcm9j ZXNzLiBTaW5jZSBTSURSIGlzIG5vdCB1c2VkIGluIFZQTiBuZXR3b3JrcyBhdCBhbGwsIHdlIGRp ZG7igJl0IHNlZSB0aGF0DQphcyBvdmVybHkgbmVjZXNzYXJ5LCBhdCBsZWFzdCByaWdodCBub3cu DQoNCkFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNClRoYW5rcywNCg0KV2VzDQoNCg0KDQoNCk9u IDEvMTgvMTQsIDEyOjUwIFBNLCAiVVRUQVJPLCBKQU1FUyIgPGp1MTczOEBhdHQuY29tPiB3cm90 ZToNCg0KPkl0IHdvdWxkIHNlZW0gdG8gbWUgdGhhdCB0aGlzIGlzIHByaW1hcmlseSBpbmZvcm1h dGlvbmFsIGluIG5hdHVyZS4gVGhlcmUNCj5hcmUgb3RoZXIgbWV0aG9kcyBvZiBtYW5pcHVsYXRp bmcgQVMtUEFUSCBpLmUgQVNfT1ZFUlJJREUgdGhhdCBhcmUgdXNlZC4NCj5BcyB0aGVzZSB0b29s cyBhcmUgYWxzbyB1c2VkIGluIG90aGVyIHNwYWNlcyBpLmUgVlBOIGl0IHdvdWxkIHNlZW0NCj5w cnVkZW50IHRvIGluY2x1ZGUgb3RoZXIgdXNlIGNhc2VzLi4gT25lIGlzIHRoZSBhYmlsaXR5IHRv IGhhdmUgbXVsdGlwbGUNCj5jdXN0b21lciBlbmRwb2ludHMgdXNpbmcgdGhlIHNhbWUgQVMgdG8g Y29tbXVuaWNhdGUgb3ZlciB0aGUgU1BzIG5ldHdvcmsuDQo+SW4gdGhpcyBjYXNlIGFuIGFwcHJv YWNoIG1heSBiZSB0byB1c2UgQVNfT1ZFUlJJREUgdG8gZGlzYWJsZSB0aGUgQVNfUEFUSA0KPmxv b3AgcHJldmVudGlvbiBtZXRob2QuLg0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9y bWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8g Y29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRp c3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJl bGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwg aXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29w eSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Fri Feb 14 08:06:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E273C1A00A3 for ; Thu, 13 Feb 2014 18:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGjCAtswEtIr for ; Thu, 13 Feb 2014 18:53:42 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 247171A0016 for ; Thu, 13 Feb 2014 18:53:42 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 93FC47FC39C; Thu, 13 Feb 2014 18:53:40 -0800 (PST) To: pst@cisco.com, rchandra@cisco.com, tli@skat.usc.edu, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20140214025340.93FC47FC39C@rfc-editor.org> Date: Thu, 13 Feb 2014 18:53:40 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/cCSdRukN3DcVfATXNvfJ6Bi3EvI X-Mailman-Approved-At: Fri, 14 Feb 2014 08:06:34 -0800 Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC1997 (3890) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 02:53:44 -0000 The following errata report has been submitted for RFC1997, "BGP Communities Attribute". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=1997&eid=3890 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 3 Original Text ------------- " The community attribute values ranging from 0x0000000 through 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved." Corrected Text -------------- " The community attribute values ranging from 0x00000000 through 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved." Notes ----- Since community is a 32-bit value, 0x0000000 should be 0x00000000 to remove confusion. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC1997 (no draft string recorded) -------------------------------------- Title : BGP Communities Attribute Publication Date : August 1996 Author(s) : R. Chandra, P. Traina, T. Li Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Feb 14 10:07:40 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598F31A037E; Fri, 14 Feb 2014 10:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdfzyLF-te0p; Fri, 14 Feb 2014 10:07:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 333D81A0398; Fri, 14 Feb 2014 10:07:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214180733.8522.14729.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 10:07:33 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/PaFysxL3YwqV2TEFqnReMSscrUs Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:07:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Revised Error Handling for BGP UPDATE Messages Authors : Enke Chen Juniper Networks Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-06.txt Pages : 14 Date : 2014-02-14 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, and 5701. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 11:53:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93571A0350 for ; Fri, 14 Feb 2014 11:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg7yiogKDd6t for ; Fri, 14 Feb 2014 11:53:34 -0800 (PST) Received: from mail.crfreenet.org (mail6.crfreenet.org [IPv6:2002:515c:9101:20::10]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2941A0317 for ; Fri, 14 Feb 2014 11:52:51 -0800 (PST) Received: from localhost (ip-89-102-22-52.net.upcbroadband.cz [89.102.22.52]) by mail.crfreenet.org (Postfix) with ESMTP id 2349AFCD2; Fri, 14 Feb 2014 20:52:48 +0100 (CET) Received: from santiago by localhost with local (Exim 4.69) (envelope-from ) id 1WEPMB-0006RY-I2; Fri, 14 Feb 2014 21:27:31 +0100 Date: Fri, 14 Feb 2014 21:27:31 +0100 From: Ondrej Zajicek To: Hannes Gredler , Jakob Heitz Message-ID: <20140214202731.GA15489@localhost> References: <20140213160647.GZ13804@localhost> <20140213232832.GD3701@juniper.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <20140213232832.GD3701@juniper.net> X-Operating-System: Debian GNU/Linux User-Agent: Mutt/1.5.18 (2008-05-17) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/d0A_eFmgPNA_I-juh4kOhcI6tj4 Cc: idr@ietf.org Subject: Re: [Idr] Possible problem in RFC 4724 Graceful restart? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:53:37 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 14, 2014 at 12:28:32AM +0100, Hannes Gredler wrote: > | 3) But if both R1 and R2 support graceful restart, but R1 is configured > | as receiver-only, then R1 closes the first connection (according to RFC > | 4724), but R2 simultaneously closes the second connection (because R1 > | announces graceful restart capability without any AFI/SAFI, therefore > | modifications of FSM from RFC 4724 do not apply). After that both > | speakers realise that the other connection is also down and after some > | timeout they would try to reestablish the session, perhaps with the same > | result. > |=20 > | Is such problem possible, or i am misinterpreting RFC 4724? >=20 > in theory yes, practially speaking BGP implementations have a > reconnect timer which gets jittered a bit, such that > on subsequent bringup attempts, colissions are less likely. Thanks for answers. The probability of such problem depends mainly of how wide is a window for collisions, which depends on exact interpretation of FSM from RFC 4271, which is IMHO rather vague w.r.t. collisions. I will address this in a separate e-mail. --=20 Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAlL+fDMACgkQw1GB2RHercPBrwCffV0D3P/mVXFIguP6BwQaOR8S XA4AmwUlNgadsVv8chXxuGSJ+TEsT/Eq =gXJi -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From nobody Fri Feb 14 11:53:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83B21A0365 for ; Fri, 14 Feb 2014 11:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOZE_acW7Cel for ; Fri, 14 Feb 2014 11:53:38 -0800 (PST) Received: from mail.crfreenet.org (mail6.crfreenet.org [IPv6:2002:515c:9101:20::10]) by ietfa.amsl.com (Postfix) with ESMTP id F1E081A0375 for ; Fri, 14 Feb 2014 11:53:03 -0800 (PST) Received: from localhost (ip-89-102-22-52.net.upcbroadband.cz [89.102.22.52]) by mail.crfreenet.org (Postfix) with ESMTP id DB681FCD2; Fri, 14 Feb 2014 20:53:01 +0100 (CET) Received: from santiago by localhost with local (Exim 4.69) (envelope-from ) id 1WEPMG-0006Rs-A1; Fri, 14 Feb 2014 21:27:36 +0100 Date: Fri, 14 Feb 2014 21:27:36 +0100 From: Ondrej Zajicek To: idr@ietf.org Message-ID: <20140214202736.GB15489@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline X-Operating-System: Debian GNU/Linux User-Agent: Mutt/1.5.18 (2008-05-17) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/pc6e4P_T6BEUPZoSHIq1AMUjTqE Subject: [Idr] BGP FSM vague and contradictory w.r.t. collisions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:53:42 -0000 --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi RFC 4721 is rather vague w.r.t. BGP connection collisions and related FSMs. Paragraph 8.2.1. specifies: A BGP implementation will have, at most, one FSM for each configured peering, plus one FSM for each incoming TCP connection for which the peer has not yet been identified. Each FSM corresponds to exactly one TCP connection. That means that we have a 'primary' FSM for a peer and 'auxiliary' FSM when a new incoming TCP connection is accepted. Question is where these two FSMs get merged. According to the mentioned paragraph, auxiliary FSM is here only when 'the peer has not yet been identified', which means that it is in OpenSent state (since in OpenConfirm, the identity / router ID of the peer is known). What happens when the auxiliary FSM changes from OpenSent to OpenConfirm? That depends on the state of the primary FSM: If the primary FSM is in OpenConfirm or higher, then procedures from 6.8. BGP Connection Collision Detection applies, one connection is closed and one FSM remains, so there is no problem. But what happens if the primary FSM is in OpenSent or even in a lower state? Par. 8.2.1 mentioned above implicitly says that one FSM has to be eliminated, but Par. 6.8. does not handle such case and FSM description in 8.2.2. gives some clues that it should still exist, e.g. events 16 (outgoing TCP accepted) and 17 (incoming TCP accepted) are specified in higher states for 'the other connection', but if there is no FSM in state Connect, then event 16 cannot happen and only event 17 is relevant for 'the other connection'. I see three possible ways how to handle this situation (auxiliary FSM in OpenSent->OpenConfirm transition, while primary FSM state <=3D OpenSent): 1) Kill primary FSM and related state (and replace it with auxiliary FSM). This is consistent with 8.2.1., but it is against the spirit of 6.8. and killing an outgoing connection which is already in OpenSent state is not specified anywhere in 8.2.2. and probably not a good idea. 2) Kill primary FSM (and related state) when it is in Connect or Active state, but keep it when it is in OpenSent state. This is not strictly consistent with 6.8., 8.2.1., or 8.2.2., but it is probably most compatible and least intrusive change. 3) Keep primary FSM independently to auxiliary FSM and continue it until it advances fo OpenConfirm, then solve it according to 6.8.. This is consistent with 8.2.2., but hard violation of 8.2.1.. It also expands collision window so most BGP session establishment attempts would contain collision handling. What do you think is a proper way for a BGP implementation to handle this c= ase? --=20 Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAlL+fDgACgkQw1GB2RHercN7PwCeO4QkjsjT5HoUVQowigVm1FZB RLsAnRWOPsjvihxoU8DClKRYBF/zg29L =bQko -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- From nobody Fri Feb 14 13:14:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2551A03DF; Fri, 14 Feb 2014 13:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8Jzirr7K6TP; Fri, 14 Feb 2014 13:14:38 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 30F451A043A; Fri, 14 Feb 2014 13:14:34 -0800 (PST) Received: from [IPv6:2601:4:2180:300:7ed1:c3ff:feec:5ab7] ([IPv6:2601:4:2180:300:7ed1:c3ff:feec:5ab7]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id s1ELETrT000455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 16:14:29 -0500 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Fri, 14 Feb 2014 16:14:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Sander Steffann X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [IPv6:2001:418:3f4::5]); Fri, 14 Feb 2014 16:14:30 -0500 (EST) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/bXrSna3NhgvriZQAV_RJt3wV3rw Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:14:40 -0000 On Feb 14, 2014, at 3:13 PM, Sander Steffann wrote: > Hi, >=20 >>> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >>> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >>> 2014-02-12 >>=20 >> please no. if you can not assign a unique four octet integer to each >> router in your network, then you have much bigger problems. and = adding >> a capability and more complexity to try to patch over your inability = to >> configure your routers will just compound your problems. >=20 > I agree. It's a shame that the router-id looks like an IPv4 address = and IPv4 addresses are used to auto-configure it when the operator = doesn't explicitly set it. There are too many people that think that a = router-id is more than a 32-bit number and must be an IPv4 address, but = creating more complexity to avoid educating router operators isn't the = answer... +1 Perhaps this is another thing like ASDOT vs ASPLAIN where we can shift = the configuration on devices to accept a decimal number? - Jared= From nobody Fri Feb 14 13:17:21 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233BE1A0375; Fri, 14 Feb 2014 13:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peTdDHRcEVU1; Fri, 14 Feb 2014 13:17:13 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id CE34E1A02C0; Fri, 14 Feb 2014 13:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1599; q=dns/txt; s=iport; t=1392412631; x=1393622231; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lymx2vxGX8hLLnnVSCeoveMxqGzTh1Z3qu2p4ufGTgs=; b=J/23bBPjJ6hIAfJj47X9DtT985vDbQcPyyj6JT6lh81gLbVGJX8ZnAVI qd+yWw8QM1sAdgHWUsJXFZFb9YowrMofiv29VpPnpndNx1bxNTjeXm9J4 d4kPupaym9v6hf7AgzM1qNXoF0obIet5iVLErGKTb4nruHlQDp6ur5wOc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAK+G/lKtJV2Y/2dsb2JhbABZgwY4wAaBGBZ0giUBAQEDAQEBATc0CwULAgEIGB4QJwslAgQOBYd9CA3ITxeORjMHgySBFASYLIEykHGDLQ X-IronPort-AV: E=Sophos;i="4.95,847,1384300800"; d="scan'208";a="20600500" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 14 Feb 2014 21:17:11 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1ELHBJT023416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 21:17:11 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.214]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 15:17:10 -0600 From: "Rajiv Asati (rajiva)" To: Sander Steffann Thread-Topic: [v6ops] BGP Identifier Thread-Index: AQHPKcE/TYiQMAjLk0S8LJu44RYd7Zq1QLyf Date: Fri, 14 Feb 2014 21:17:09 +0000 Message-ID: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/KObP4OKJ7Ivdy5XdcMOq3Nq142k Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:17:15 -0000 +1.=20 We had a bit of discussion on MPLS WG ~2yrs ago during LDP-ipv6 formulation= and we managed to quickly put the suggestion about LDP router-id being a 1= 28-bit entity in the back burner.=20 Good or bad - many vendor implementations historically tied router-id to an= interface in addition or instead of a 4-context entity. Thankfully, many h= ave already evolved to not continue with that model in the v6 paradigm. Jus= t a matter of time for others to catch up.=20 Cheers, Rajiv > On Feb 14, 2014, at 2:13 PM, "Sander Steffann" wrote= : >=20 > Hi, >=20 >>> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >>> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >>> 2014-02-12 >>=20 >> please no. if you can not assign a unique four octet integer to each >> router in your network, then you have much bigger problems. and adding >> a capability and more complexity to try to patch over your inability to >> configure your routers will just compound your problems. >=20 > I agree. It's a shame that the router-id looks like an IPv4 address and I= Pv4 addresses are used to auto-configure it when the operator doesn't expli= citly set it. There are too many people that think that a router-id is more= than a 32-bit number and must be an IPv4 address, but creating more comple= xity to avoid educating router operators isn't the answer... >=20 > Cheers, > Sander >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 14 13:56:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0681D1A03EA; Fri, 14 Feb 2014 13:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaGqxwrC-K5l; Fri, 14 Feb 2014 13:56:40 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 971891A041E; Fri, 14 Feb 2014 13:56:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XRGro/O9N76JkbeyYo57ODtPkn9zgsBefJXR/wIbrScpuHdLJP7coHF2oSy6UIHy; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [76.21.83.101] (helo=[10.0.1.2]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WEQkK-0002rt-1C; Fri, 14 Feb 2014 16:56:32 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Mitchell Erblich In-Reply-To: Date: Fri, 14 Feb 2014 13:56:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec798185fcf19880707e8156002497107ca4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.21.83.101 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/1fOtSx0ihkCS-Uctfn_v_8GDtLA Cc: idr wg , V6 Ops List , Fred Baker Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:56:43 -0000 For some minor consistency, =20 I think that some LAN protocols prefer a loopback (assume always up) = addr and then secondarily an interface addr. Mitchell Erblich On Feb 14, 2014, at 1:05 AM, Robert Raszuk wrote: > I agree with Randy'a point here.=20 >=20 > BGP rtr_id does not need to be a routable address - it just needs to = be unique 32 bits within the domain scope.=20 >=20 > We have had this discussion already during RFC6286 and concluded that = 4 octet is sufficient for any type of BGP mesh.=20 >=20 > If anything I would propose to go opposite and to ask your = implementation to allow UTF-8 encoded BGP rtr_id format.=20 >=20 > Rgs, > R. >=20 >=20 > On Fri, Feb 14, 2014 at 7:51 AM, Randy Bush wrote: > > http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id > > "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang = Li, > > 2014-02-12 >=20 > please no. if you can not assign a unique four octet integer to each > router in your network, then you have much bigger problems. and = adding > a capability and more complexity to try to patch over your inability = to > configure your routers will just compound your problems. >=20 > randy >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Feb 14 16:09:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE7C1A01DD; Fri, 14 Feb 2014 16:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_umKHDPaFTG; Fri, 14 Feb 2014 16:09:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 19CAA1A0140; Fri, 14 Feb 2014 16:09:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WESos-000322-Oh; Sat, 15 Feb 2014 00:09:23 +0000 Date: Sat, 15 Feb 2014 09:09:21 +0900 Message-ID: From: Randy Bush To: Mitchell Erblich In-Reply-To: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/YOACwFkcm4H7uiyS5HbskUf58wU Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:09:27 -0000 > I think that some LAN protocols prefer a loopback (assume always up) > addr and then secondarily an interface addr. interesting. and what LAN protocols use the BGP RouterID? randy From nobody Fri Feb 14 16:49:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3520A1A01E2; Fri, 14 Feb 2014 16:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPoEd4F_jE1O; Fri, 14 Feb 2014 16:49:12 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 821371A0212; Fri, 14 Feb 2014 16:49:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gjwbHH3s5kyTCpfu1lnK7xTWZ9nYk/I6jx7H41WcfcSpHEAvk1ujB5flWQTPQGPz; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [76.21.83.101] (helo=[10.0.1.2]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WETRO-0000jL-8r; Fri, 14 Feb 2014 19:49:10 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Mitchell Erblich In-Reply-To: Date: Fri, 14 Feb 2014 16:49:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <916A3488-34C9-4A12-BE98-0465978CB41B@earthlink.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79792f28e0e5f181b2a3e71d40ce8c08c8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.21.83.101 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/03razcQOuwnHzz1f__IeHdZ6Wlg Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:49:14 -0000 Randy A router-id is a router-id. Do you think that every protocol that is enabled on the router = should have a different router-id? So, if you have enabled RIP, OSPFv2, OSPFv3, ISIS, BGP, etc, = then for consistency basis, I think the router SHOULD have 1 router-id.. Now=85 how many implementations have 1 and why shouldn't an = admin attempt to have a router with as few router-ids as possible? Best = 1 unique router-id accross all its enabled and not enabled protocols. So, if you redistributes OSPF routes into BGP (RFC 1403), = wouldn't is be easier to admin with each router having a single = router-id? Mitchell Erblich On Feb 14, 2014, at 4:09 PM, Randy Bush wrote: >> I think that some LAN protocols prefer a loopback (assume always up) >> addr and then secondarily an interface addr. >=20 > interesting. and what LAN protocols use the BGP RouterID?=20 >=20 > randy From nobody Fri Feb 14 17:47:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4C31A00A7; Fri, 14 Feb 2014 17:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqAZtsOpDN-u; Fri, 14 Feb 2014 17:47:40 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3881A1A0018; Fri, 14 Feb 2014 17:47:40 -0800 (PST) Received: from [192.168.1.7] (pool-72-73-23-184.clppva.fios.verizon.net [72.73.23.184]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id s1F1lavc004489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 20:47:37 -0500 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <916A3488-34C9-4A12-BE98-0465978CB41B@earthlink.net> From: Jon Mitchell In-Reply-To: <916A3488-34C9-4A12-BE98-0465978CB41B@earthlink.net> Message-Id: <1954AEE5-C355-42DD-B102-F25488AFBD7F@puck.nether.net> Date: Fri, 14 Feb 2014 20:47:22 -0500 To: Mitchell Erblich Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11B554a) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Fri, 14 Feb 2014 20:47:37 -0500 (EST) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/sz5BdRRDm1zYv4h0lIL8cW7m7lo Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:47:41 -0000 > On Feb 14, 2014, at 7:49 PM, Mitchell Erblich wro= te: >=20 > Randy >=20 > A router-id is a router-id. >=20 > Do you think that every protocol that is enabled on the router should ha= ve a different router-id? >=20 > So, if you have enabled RIP, OSPFv2, OSPFv3, ISIS, BGP, etc, then for co= nsistency basis, I think the router SHOULD have 1 router-id.. Well, this seems an interesting argument. This capability is proposed as a p= roblem for IPv6 only networks needing a 128 bit identifier.=20 Randy argues for local assignment of 32 bit identifier as sufficient for BGP= and you say not good enough for consistency sake you want all protocols to c= hoose the same loopback based number naming 3 protocols that have 32 bit ide= ntifiers, 1 protocol with no identifier, and 1 protocol with 48 bit sys-id. = Since RIP is mentioned, why not throw in EIGRP (32 bit) as well, since this= supports IPv6 unlike OSPFv2... So looking at the list I think we can all say for consistency and simplicity= across protocols operator should prefer 32 bit values based on local loopba= ck if IPv4 enabled, or 32 bit self administered numbers if IPv6 only so they= can keep one identifier recognizable across all protocols for their routers= w/o extending every protocol in the list to support 128 bit identifiers... -Jon From nobody Fri Feb 14 21:58:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3112D1A0043 for ; Fri, 14 Feb 2014 21:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmTKHopjIwwQ for ; Fri, 14 Feb 2014 21:57:55 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 394DD1A0035 for ; Fri, 14 Feb 2014 21:57:55 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 78DF8300082 for ; Sat, 15 Feb 2014 05:57:53 +0000 (UTC) Received: from [172.16.15.4] (97-122-112-90.hlrn.qwest.net [97.122.112.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id D281E300081; Fri, 14 Feb 2014 22:57:52 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: Date: Fri, 14 Feb 2014 19:58:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Sander Steffann X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Feb 14 22:57:53 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 52ff01e142071630633117 X-DSPAM-Factors: 27, within+#+#+of, 0.40000, is+#+#+#+32, 0.40000, complexity+#+#+educating, 0.40000, 32+#+number, 0.40000, please+#+#+#+can, 0.40000, Steffann+#+steffann, 0.40000, many+#+#+#+that, 0.40000, if+#+#+are, 0.40000, and+#+lose, 0.40000, casting+an, 0.40000, Hi+IPv6, 0.40000, you+#+shane, 0.40000, using+#+#+#+to, 0.40000, two+points, 0.40000, complexity+#+#+#+router, 0.40000, an+#+#+#+allows, 0.40000, availability+#+location, 0.40000, octet+#+#+each, 0.40000, unique+#+#+integer, 0.40000, many+people, 0.40000, the+#+I, 0.40000, future+#+#+ever, 0.40000, think+that, 0.40000, purporting+#+have, 0.40000, to+#+the, 0.40000, compound+#+problems, 0.40000, creating+#+#+#+avoid, 0.40000 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/a_BvEC32jYXuCJXBdx7ozAr79YQ Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 05:57:57 -0000 Hi, I'm not casting an opinion either way wrt this specific draft; however, = I do wish to make two points below. On Feb 14, 2014, at 12:13 PM, Sander Steffann = wrote: > Hi, >=20 >>> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >>> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >>> 2014-02-12 >>=20 >> please no. if you can not assign a unique four octet integer to each >> router in your network, then you have much bigger problems. and = adding >> a capability and more complexity to try to patch over your inability = to >> configure your routers will just compound your problems. >=20 > I agree. It's a shame that the router-id looks like an IPv4 address = and IPv4 addresses are used to auto-configure it when the operator = doesn't explicitly set it. There are too many people that think that a = router-id is more than a 32-bit number and must be an IPv4 address, but = creating more complexity to avoid educating router operators isn't the = answer... I would take exception to a ROUTER_ID being just a 32-bit integer. = Specifically, when a ROUTER_ID is an IP address that allows an operator = to quickly perform diagnosis & troubleshooting using = ping/traceroute/etc. to identify the availability and location within = the topology of the router purporting to have said ROUTER_ID. The other question I would raise is, in a far-off future, if we ever = manage to get networks converted away from dual-stack and back to a = single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you = lose those capabilities mentioned above ... would you care? -shane From nobody Sat Feb 15 00:58:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C009C1A0141; Sat, 15 Feb 2014 00:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw9--dg_uX_x; Sat, 15 Feb 2014 00:58:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4861A013C; Sat, 15 Feb 2014 00:58:17 -0800 (PST) Received: from [160.249.232.91] (helo=u1032091.xgsnun101.imtp.tachikawa.mopera.net) by psg.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WEb2m-0005dK-U6; Sat, 15 Feb 2014 08:58:09 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----OYZSPWB6ND83VK03DRYZFHV6VYZF6T" Content-Transfer-Encoding: 8bit From: Randy Bush Date: Sat, 15 Feb 2014 17:55:49 +0900 To: Shane Amante ,Sander Steffann Message-ID: <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/idr/PCMWII22Vmx296yRPFzAvq0g0F8 Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 08:58:21 -0000 ------OYZSPWB6ND83VK03DRYZFHV6VYZF6T Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I use this funny thing called DNS. -- Phones are not computers and suck for email On February 15, 2014 12:58:53 PM GMT+09:00, Shane Amante wrote: >Hi, > >I'm not casting an opinion either way wrt this specific draft; however, >I do wish to make two points below. > >On Feb 14, 2014, at 12:13 PM, Sander Steffann >wrote: >> Hi, >> >>>> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >>>> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >>>> 2014-02-12 >>> >>> please no. if you can not assign a unique four octet integer to >each >>> router in your network, then you have much bigger problems. and >adding >>> a capability and more complexity to try to patch over your inability >to >>> configure your routers will just compound your problems. >> >> I agree. It's a shame that the router-id looks like an IPv4 address >and IPv4 addresses are used to auto-configure it when the operator >doesn't explicitly set it. There are too many people that think that a >router-id is more than a 32-bit number and must be an IPv4 address, but >creating more complexity to avoid educating router operators isn't the >answer... > >I would take exception to a ROUTER_ID being just a 32-bit integer. >Specifically, when a ROUTER_ID is an IP address that allows an operator >to quickly perform diagnosis & troubleshooting using >ping/traceroute/etc. to identify the availability and location within >the topology of the router purporting to have said ROUTER_ID. > >The other question I would raise is, in a far-off future, if we ever >manage to get networks converted away from dual-stack and back to a >single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you >lose those capabilities mentioned above ... would you care? > >-shane ------OYZSPWB6ND83VK03DRYZFHV6VYZF6T Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I use this funny thing called DNS.
--
Phones are not computers and suck for email

On February 15, 2014 12:58:53 PM GMT+09:00, Shane Amante <shane@castlepoint.net> wrote:
Hi,

I'm not casting an opinion either way wrt this specific draft; however, I do wish to make two points below.

On Feb 14, 2014, at 12:13 PM, Sander Steffann <sander@steffann.nl> wrote:
 Hi,
 
 http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id
 "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li,
 2014-02-12
 
 please no.  if you can not assign a unique four octet integer to each
 router in your network, then you have much bigger problems.  and
adding
 a capability and more complexity to try to patch over your inability to
 configure your routers will just compound your problems.
 
 I agree. It's a shame that the router-id looks like an IPv4 address and IPv4 addresses are used to auto-configure it when the operator doesn't explicitly set it. There are too many people that think that a router-id is more than a 32-bit number and must be an IPv4 address, but creating more complexity to avoid educating router operators isn't the answer...

I would take exception to a ROUTER_ID being just a 32-bit integer.  Specifically, when a ROUTER_ID is an IP address that allows an operator to quickly perform diagnosis & troubleshooting using ping/traceroute/etc. to identify the availability and location within the topology of the router purporting to have said ROUTER_ID.

The other question I would raise is, in a far-off future, if we ever manage to get networks
converted away from dual-stack and back to a single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you lose those capabilities mentioned above ... would you care?

-shane

------OYZSPWB6ND83VK03DRYZFHV6VYZF6T-- From nobody Sat Feb 15 07:13:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC521A024E for ; Sat, 15 Feb 2014 07:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78KNpUFr2NL6 for ; Sat, 15 Feb 2014 07:13:13 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id B67501A0257 for ; Sat, 15 Feb 2014 07:13:13 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id BB851300082 for ; Sat, 15 Feb 2014 15:13:11 +0000 (UTC) Received: from [172.16.15.4] (97-122-112-90.hlrn.qwest.net [97.122.112.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id A752330007B; Sat, 15 Feb 2014 08:13:10 -0700 (MST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2AC95F52-11F7-4B7E-9D1C-24D553E131F1" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> Date: Sat, 15 Feb 2014 07:13:10 -0800 Message-Id: <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> To: Randy Bush X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Feb 15 08:13:11 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 52ff840742072138718422 X-DSPAM-Factors: 27, within+#+#+of, 0.40000, within+#+#+of, 0.40000, is+#+#+#+32, 0.40000, is+#+#+#+32, 0.40000, complexity+#+#+educating, 0.40000, complexity+#+#+educating, 0.40000, 32+#+number, 0.40000, 32+#+number, 0.40000, please+#+#+#+can, 0.40000, please+#+#+#+can, 0.40000, Steffann+#+steffann, 0.40000, Steffann+#+steffann, 0.40000, many+#+#+#+that, 0.40000, many+#+#+#+that, 0.40000, if+#+#+are, 0.40000, if+#+#+are, 0.40000, and+#+lose, 0.40000, and+#+lose, 0.40000, casting+an, 0.40000, casting+an, 0.40000, Hi+IPv6, 0.40000, Hi+IPv6, 0.40000, you+#+shane, 0.40000, you+#+shane, 0.40000, using+#+#+#+to, 0.40000, using+#+#+#+to, 0.40000, two+points, 0.40000 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/syN3hlbfYM2B386lOXk2nT9EqWE Cc: idr wg , V6 Ops List , Sander Steffann Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 15:13:16 -0000 --Apple-Mail=_2AC95F52-11F7-4B7E-9D1C-24D553E131F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 15, 2014, at 12:55 AM, Randy Bush wrote: > I use this funny thing called DNS.=20 And that has what to do with the problem of determining liveness or = determining where in the topology is a ROUTER_ID? -shane > --=20 > Phones are not computers and suck for email >=20 > On February 15, 2014 12:58:53 PM GMT+09:00, Shane Amante = wrote: > Hi, >=20 > I'm not casting an opinion either way wrt this specific draft; = however, I do wish to make two points below. >=20 > On Feb 14, 2014, at 12:13 PM, Sander Steffann = wrote: > Hi, > =20 > http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id > "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, > 2014-02-12 > =20 > please no. if you can not assign a unique four octet integer to each > router in your network, then you have much bigger problems. and > adding > a capability and more complexity to try to patch over your inability = to > configure your routers will just compound your problems. > =20 > I agree. It's a shame that the router-id looks like an IPv4 address = and IPv4 addresses are used to auto-configure it when the operator = doesn't explicitly set it. There are too many people that think that a = router-id is more than a 32-bit number and must be an IPv4 address, but = creating more complexity to avoid educating router operators isn't the = answer... >=20 > I would take exception to a ROUTER_ID being just a 32-bit integer. = Specifically, when a ROUTER_ID is an IP address that allows an operator = to quickly perform diagnosis & troubleshooting using = ping/traceroute/etc. to identify the availability and location within = the topology of the router purporting to have said ROUTER_ID. >=20 > The other question I would raise is, in a far-off future, if we ever = manage to get networks > converted away from dual-stack and back to a single AFI -- namely, = IPv6 -- if ROUTER_ID's are only 32-bits and you lose those capabilities = mentioned above ... would you care? >=20 > -shane >=20 --Apple-Mail=_2AC95F52-11F7-4B7E-9D1C-24D553E131F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 15, 2014, at 12:55 AM, Randy = Bush <randy@psg.com> = wrote:
I use this funny thing called DNS. =

And that has what to do with the problem = of determining liveness or determining where in the topology is a = ROUTER_ID?

-shane


--
Phones are not computers and suck for email

On February 15, 2014 12:58:53 PM GMT+09:00, Shane = Amante <shane@castlepoint.net> = wrote:
Hi,

I'm not casting an opinion either way =
wrt this specific draft; however, I do wish to make two points =
below.

On Feb 14, 2014, at 12:13 PM, Sander Steffann <sander@steffann.nl> =
wrote:
 Hi,
 =

 http://tools=
.ietf.org/html/draft-fan-idr-ipv6-bgp-id
 "IPv6 BGP Identifier =
Capability for BGP-4", Peng Fan, Zhenqiang Li,
 =
2014-02-12
 
 please no.  if you can not assign a =
unique four octet integer to each
 router in your network, then you =
have much bigger problems.  and
adding
 a capability and more complexity to try to patch over your =
inability to
 configure your routers will just compound your =
problems.
 
 I agree. It's a shame that the router-id =
looks like an IPv4 address and IPv4 addresses are used to auto-configure =
it when the operator doesn't explicitly set it. There are too many =
people that think that a router-id is more than a 32-bit number and must =
be an IPv4 address, but creating more complexity to avoid educating =
router operators isn't the answer...

I would take =
exception to a ROUTER_ID being just a 32-bit integer.  Specifically, =
when a ROUTER_ID is an IP address that allows an operator to quickly =
perform diagnosis & troubleshooting using ping/traceroute/etc. to =
identify the availability and location within the topology of the router =
purporting to have said ROUTER_ID.

The other question I would =
raise is, in a far-off future, if we ever manage to get networks
converted away from dual-stack and back to a single AFI -- namely, IPv6 =
-- if ROUTER_ID's are only 32-bits and you lose those capabilities =
mentioned above ... would you =
care?

-shane

= --Apple-Mail=_2AC95F52-11F7-4B7E-9D1C-24D553E131F1-- From nobody Sat Feb 15 07:53:47 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F49A1A00EF for ; Sat, 15 Feb 2014 07:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkOkSseylBZl for ; Sat, 15 Feb 2014 07:53:43 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id C27211A00EA for ; Sat, 15 Feb 2014 07:53:43 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 15C4230007B for ; Sat, 15 Feb 2014 15:53:42 +0000 (UTC) Received: from [172.16.15.4] (97-122-112-90.hlrn.qwest.net [97.122.112.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 67F8B30007A; Sat, 15 Feb 2014 08:53:41 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> Date: Sat, 15 Feb 2014 07:53:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <32ACD29A-AF81-498F-B849-A018D928591F@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Feb 15 08:53:42 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 52ff8d8642071629916001 X-DSPAM-Factors: 27, records+#+#+#+3, 0.40000, in+networks, 0.40000, Steffann+#+steffann, 0.40000, unfamiliar+with, 0.40000, has+#+#+often, 0.40000, can+always, 0.40000, DNS+And, 0.40000, past+#+#+#+found, 0.40000, helpful+in, 0.40000, to+#+the, 0.40000, do+#+the, 0.40000, time+#+#+using, 0.40000, hey+#+#+always, 0.40000, isis+#+#+finding, 0.40000, it+#+#+#+in, 0.40000, wrote+#+use, 0.40000, is+#+#+#+i, 0.40000, do+#+#+problem, 0.40000, wrote+Op, 0.40000, more+#+than, 0.40000, networks+#+I've, 0.40000, that+#+#+#+out, 0.40000, tell+#+#+that, 0.40000, diagnosing+#+#+brokenness, 0.40000, where+#+#+#+is, 0.40000, where+#+#+#+is, 0.40000, in+#+#+#+duplicate, 0.40000 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Arb6sW607BUgf_p74-pHqxW-6Gk Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 15:53:45 -0000 On Feb 15, 2014, at 7:26 AM, Sander Steffann wrote: > Op 15 feb. 2014, om 16:13 heeft Shane Amante = het volgende geschreven: >> On Feb 15, 2014, at 12:55 AM, Randy Bush wrote: >>> I use this funny thing called DNS.=20 >>=20 >> And that has what to do with the problem of determining liveness or = determining where in the topology is a ROUTER_ID? >=20 > And what does an integer called ROUTER_ID tell you about that? In my past experience, I have found that -- particularly in new networks = that I'm unfamiliar with -- looking at the output of "show (ospf|isis) = database extensive", finding a ROUTER_ID that originated the LSA/LSPDU = and performing a ping and/or traceroute to it to verify the sanity of = where in the topology that ROUTER_ID is located has been helpful in = rapidly diagnosing and fixing brokenness. Yes, I will admit that it is = not a panacea (i.e.: it does not help in the case of duplicate = ROUTER_ID's), but 99% of the time it's often using that information to = figure out where traffic is, or is not, going to. Look, it's your network, do whatever pleases you. But, in networks that = I've run, having congruency between the ROUTER_ID and a Loopback address = has helped more often than not. > And hey, you can always create records like > 1.2.3.4.router-id.castlepoint.net IN CNAME = router1.somewhere.castlepoint.net And, when your DNS server is unreachable because you've got a network = issue, what then? -shane= From nobody Sat Feb 15 10:37:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C6A1A0274; Sat, 15 Feb 2014 10:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_FROM=2.3, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVxl5IRQVpbl; Sat, 15 Feb 2014 10:37:49 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 38AD01A026E; Sat, 15 Feb 2014 10:37:49 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so10138940lbv.38 for ; Sat, 15 Feb 2014 10:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=e03H8yrtuHfpXKfPuUMvx9LCVdLWHB5BjRQWsREgUE8=; b=MtsN1Po/2wz2aa5TnpcIQHr8qdJEvHqNOhBmaOQLZ5F15bxL0R1ZFHhNFtA5JZEm3Q 6TkhMBwQbNYkDmt+MCcyc3Mbml5mhOG/NTIVmIK96vEMwcXs4t0dj5B+q7duVJqb7IIH eJE/aQC+p37tc2ecaPFRJV6n9IPhVfOsQF1IRIEfo7151qHvFBxRQg8AAhFRGj5juJoj gKL4H0ai9Nov5d6cdyEmRJUUMYF4mEvWf9JOGEp8FKT8z6VUC7pCm2ZzxOdtTmkjvxTx 8yGwmVEJtFLqyJUVkRKVJsnP8HhEZB9IQ+JyzQS263S3LqB/NHjNS/fobfFc5KFmPE1/ 3+7Q== MIME-Version: 1.0 X-Received: by 10.112.114.228 with SMTP id jj4mr10121916lbb.13.1392489466570; Sat, 15 Feb 2014 10:37:46 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.152.203.167 with HTTP; Sat, 15 Feb 2014 10:37:46 -0800 (PST) In-Reply-To: <32ACD29A-AF81-498F-B849-A018D928591F@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> <32ACD29A-AF81-498F-B849-A018D928591F@castlepoint.net> Date: Sat, 15 Feb 2014 13:37:46 -0500 X-Google-Sender-Auth: GD4lSzvTplg_64EcysF3ZqR-_Wo Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/EgOh6ycVzk4K6UsiwlHIjkHxuOw Cc: idr wg , V6 Ops List , Sander Steffann Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 18:37:51 -0000 On Sat, Feb 15, 2014 at 10:53 AM, Shane Amante wrot= e: >> And what does an integer called ROUTER_ID tell you about that? > > In my past experience, I have found that -- particularly in new networks = that I'm unfamiliar with -- looking at the output of "show (ospf|isis) data= base extensive", finding a ROUTER_ID that originated the LSA/LSPDU and perf= orming a ping and/or traceroute to it to verify the sanity of where in the = topology that ROUTER_ID is located has been helpful in rapidly diagnosing a= nd fixing brokenness. Yes, I will admit that it is not a panacea (i.e.: it= does not help in the case of duplicate ROUTER_ID's), but 99% of the time i= t's often using that information to figure out where traffic is, or is not,= going to. > for isis I think unique router-id is important (at least inside the same level? or perhaps I'm just thinking that changing the router-id is a ted update event.) but for bgp it seems less important (aside from the troubleshooting you outline). I imagine it'd actually be nice to be able to set a router-id externally and a different one internally actually. This could have some fun implications really... 'my router-id everywhere is 1!' (or zero) >> And hey, you can always create records like >> 1.2.3.4.router-id.castlepoint.net IN CNAME router1.somewhere.castlepoin= t.net > > And, when your DNS server is unreachable because you've got a network iss= ue, what then? you could, of course, replace 'dns' with any other separated mapping system (say a text file in the least complex setup). This does add more work for O&M though, which is probably bad :( extra record keeping isn't particularly good... I wonder though what's going to happen if you don't have ipv4 on the network anylonger, and have no need for ipv4 identifiers? do you just keep numbering the router-id from "some ipv4 space" or do we have to look at updating bgp to have a router-id (and isis and ospf and...) that's more than just 32 random bits that happen to look like an ip address? -chris From nobody Sat Feb 15 10:49:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571A71A0275; Sat, 15 Feb 2014 10:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIIJTXfED3H5; Sat, 15 Feb 2014 10:49:35 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3171A0273; Sat, 15 Feb 2014 10:49:35 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s1FInRkw057412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 15 Feb 2014 18:49:27 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52FFB6B7.4090408@foobar.org> Date: Sat, 15 Feb 2014 18:49:27 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sander Steffann , Shane Amante References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> In-Reply-To: <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/SWaasMITwn2XkeWTER0s19RLyIU Cc: idr wg , V6 Ops List , draft-fan-idr-ipv6-bgp-id@tools.ietf.org Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 18:49:38 -0000 On 15/02/2014 15:26, Sander Steffann wrote: > Op 15 feb. 2014, om 16:13 heeft Shane Amante het volgende geschreven: >> On Feb 15, 2014, at 12:55 AM, Randy Bush wrote: >>> I use this funny thing called DNS. >> >> And that has what to do with the problem of determining liveness or determining where in the topology is a ROUTER_ID? > > And what does an integer called ROUTER_ID tell you about that? > > And hey, you can always create records like > 1.2.3.4.router-id.castlepoint.net IN CNAME router1.somewhere.castlepoint.net guys, we're all having a bit of an ietf moment here: within the space of 48 hours, the conversation has ratholed. Let's love up a bit. The authors of the draft have a simple operational desire to make their lives a little easier and as an operator I sympathise with this, particularly because they are using ipv6-only networks in anger which is more than I do. There are two advantages of having a 128 bit router-id (with the unstated convention of tying router-id == address of first loopback): - firstly it's easy to identify the location of prefix announcements on your network - secondly the router-id can be autoconfigured. On the other hand, implementing this will require that the authors define a transition mechanism to allow 128 bit router-id routers interoperate with 32 bit router-id routers in such a way that router-id collisions don't occur. If the authors want to progress this, they need to state a stronger use case and they need to create a transition mechanism. If they can do this in a reasonable way which doesn't break backwards compatibility, then it might be appropriate for idr / v6ops / etc to take another look at the draft. Also, I wish them well because everyone understands what a router ID is and everyone will want to paint theirs a different colour. Nick From nobody Sat Feb 15 11:26:17 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0411A0214 for ; Sat, 15 Feb 2014 11:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U97bWyIUUyS8 for ; Sat, 15 Feb 2014 11:26:11 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 372C11A0268 for ; Sat, 15 Feb 2014 11:26:11 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Sat, 15 Feb 2014 13:26:08 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f174.google.com [209.85.213.174] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f174.google.com with SMTP id hl1so2734197igb.1 for ; Sat, 15 Feb 2014 11:26:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=plgJqSQ4/tOPyQ6PTC0ZHFKzNtrUs3Z5f92DWrNQYJM=; b=cInVf8pA+1SaaLzYltLSHPnsRknfLBN2FfXKgaOKsECZUE3hEgOcF7q57M0yoaqla7 BI5I8Xko/xWNGhiEB+Xv2N6aJLKeJzq5mhEjMt1Dn47qeP+0Uer6pocIs2y8HNLi9MJ5 IZP5ulQ0KXxKrAb5yFqOHUrZKfD2XNsQ+4IOV+xtmEiS/hLzQzh8/+nZyMwyOImAMcYV 8dnCkd78gttnpc9ZB8Rfl1JMbEiMF6wf851mtLCRYNXohXGB+nno5Nsk5o1eRJPrHC87 IrxfFpFj/QSK3Vvq75RaMqNTzC+SqzESSMGm0HcMCFK1uw3p5lMO/+PVTECTALh8bOnS j76g== X-Gm-Message-State: ALoCoQlRjIaJRM2JkLm6PxnLLfHUCW+EBsyjyDkuq37r/qm4kX8pq9im+logDpOmbRS7tYQXgomSG9hl232B2zTg4TeZJz5SkfOTNk6xIk2iSmk3A+Bst/k4ItWX7Yl/WlIw9fpIRyVd X-Received: by 10.42.169.134 with SMTP id b6mr11223673icz.22.1392492363281; Sat, 15 Feb 2014 11:26:03 -0800 (PST) X-Received: by 10.42.169.134 with SMTP id b6mr11223668icz.22.1392492363130; Sat, 15 Feb 2014 11:26:03 -0800 (PST) Received: from [192.168.88.248] (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPSA id gd5sm15643872igd.5.2014.02.15.11.25.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Feb 2014 11:25:59 -0800 (PST) References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> In-Reply-To: <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> X-Mailer: iPad Mail (11B554a) From: David Farmer Date: Sat, 15 Feb 2014 13:25:59 -0600 To: Shane Amante Archived-At: http://mailarchive.ietf.org/arch/msg/idr/45FnvyBHuXWmmBw5oBv6tNk_L4I Cc: idr wg , V6 Ops List , Sander Steffann Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 19:26:12 -0000 > On Feb 14, 2014, at 21:58, Shane Amante wrote: >=20 > I would take exception to a ROUTER_ID being just a 32-bit integer. Specif= ically, when a ROUTER_ID is an IP address that allows an operator to quickly= perform diagnosis & troubleshooting using ping/traceroute/etc. to identify t= he availability and location within the topology of the router purporting to= have said ROUTER_ID. >=20 > The other question I would raise is, in a far-off future, if we ever manag= e to get networks converted away from dual-stack and back to a single AFI --= namely, IPv6 -- if ROUTER_ID's are only 32-bits and you lose those capabili= ties mentioned above ... would you care? I agree it is a very common and useful operational practice to use the IPv4 l= oopback address for the ROUTER_ID. This practice is strongly reinforced in t= hat most implementations represent the ROUTER_ID in dotted quad decimal nota= tion, the same way we represent IPv4 addresses. However, common practice does not make it a protocol requirement. I would s= uggest there are several possible new operational practices that could be de= veloped that don't require complicate changes to the protocol. =20 A very simple one would be to use a common IPv6 prefix for all your /128 IPv= 6 loopback addresses and embed the ROUTER_ID as the least significant 32 bit= s. Just as implementations reinforce the current operational practice, they= could also reinforce this possible new practice by representing the 32bit R= OUTER_ID in hex instead of dotted quad decimal, or even better both represen= tations next to each other. Maybe implementations could allow you to specif= y a /96 IPv6 prefix to be appended with the ROUTER_ID when it is output, giv= ing you the IPv6 address you wanted without changing the protocol. As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205. Then yo= u can use an IPv6 loopback address of 2001:db8:1::c000:205, or you could eve= n used mixed notation 2001:db8:1::192.0.2.5. So, you do not loose the ability to "quickly perform diagnosis & troubleshoo= ting using ping/traceroute/etc. to identify the availability and location wi= thin the topology." There was also a DNS recommendation made in the thread, that would work too.= So, I'd prefer effort be put toward an informational draft suggesting operat= ional practices and maybe implementation suggestions that reinforce these su= ggestions rather than complicated protocol changes. =20 Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Sun Feb 16 08:28:42 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBCB1A00E6; Sun, 16 Feb 2014 08:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYvDWbuYyZtR; Sun, 16 Feb 2014 08:28:39 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id C56961A002C; Sun, 16 Feb 2014 08:28:38 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25300e6ac8e3-308e3; Mon, 17 Feb 2014 00:26:21 +0800 (CST) X-RM-TRANSID: 2ee25300e6ac8e3-308e3 Received: from X6X8D79D8F49E2 (unknown[125.97.246.90]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35300e6ac00d-b4a6e; Mon, 17 Feb 2014 00:26:21 +0800 (CST) X-RM-TRANSID: 2ee35300e6ac00d-b4a6e From: "Fan, Peng" To: "'Randy Bush'" , "'Fred Baker'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> In-Reply-To: Date: Mon, 17 Feb 2014 00:28:32 +0800 Message-ID: <006801cf2b34$22837cd0$678a7670$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QG64jb+mS7we9A= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/idr/0ICjTM_tTdiV4DpUQ4kq5iky4LU Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 16:28:42 -0000 Hi Randy, and all, Thanks for the discussion and sorry for the late. Assigning an id is not a difficult issue, especially on a single router. But what number is to be assigned might be an issue, especially in an ISP's large network, in order to guarantee the uniqueness of the ids. In our network this kind of numeric resources, e.g. IP addresses and cell phone numbers, is planned in advance (usually with a careful designed numbering rule), and then delivered to admins who located at different parts of the network. In the IPv4 world, we take advantage of an IPv4 address, as it by nature an ideal id and fits into the 32-bit length, and could be helpful in OAM. So perhaps we can use a similar approach in an IPv6-only world, then the admins don't have to bother to worry how to choose the ids. An id is not necessarily an IP address, but IP address is a perfect candidate for an id. Thanks and regards, Peng > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush > Sent: Friday, February 14, 2014 2:52 PM > To: Fred Baker > Cc: idr wg; V6 Ops List > Subject: Re: [Idr] [v6ops] BGP Identifier > > > http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id > > "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, > > 2014-02-12 > > please no. if you can not assign a unique four octet integer to each router in > your network, then you have much bigger problems. and adding a capability > and more complexity to try to patch over your inability to configure your routers > will just compound your problems. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sun Feb 16 08:47:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2001A03D8; Fri, 14 Feb 2014 12:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcW80BdPHxAF; Fri, 14 Feb 2014 12:13:24 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3471A03CD; Fri, 14 Feb 2014 12:13:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id B493A37; Fri, 14 Feb 2014 21:13:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDOeUIUaTBPJ; Fri, 14 Feb 2014 21:13:19 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 69A4134; Fri, 14 Feb 2014 21:13:19 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: Date: Fri, 14 Feb 2014 21:13:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Cw_Ku3maY5cpmpA6zeQlbnTVJQ4 X-Mailman-Approved-At: Sun, 16 Feb 2014 08:47:26 -0800 Cc: idr wg , V6 Ops List , Fred Baker Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:13:26 -0000 Hi, >> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >> 2014-02-12 >=20 > please no. if you can not assign a unique four octet integer to each > router in your network, then you have much bigger problems. and = adding > a capability and more complexity to try to patch over your inability = to > configure your routers will just compound your problems. I agree. It's a shame that the router-id looks like an IPv4 address and = IPv4 addresses are used to auto-configure it when the operator doesn't = explicitly set it. There are too many people that think that a router-id = is more than a 32-bit number and must be an IPv4 address, but creating = more complexity to avoid educating router operators isn't the answer... Cheers, Sander From nobody Sun Feb 16 08:47:29 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2160A1A042B; Fri, 14 Feb 2014 15:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MXJ-kZfgb6a; Fri, 14 Feb 2014 15:02:39 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 533D31A040C; Fri, 14 Feb 2014 15:02:38 -0800 (PST) Received: from [10.5.16.25] (adsl-69-228-94-95.dsl.pltn13.pacbell.net [69.228.94.95]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1EN18vf004028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Feb 2014 15:01:10 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1EN18vf004028 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392418874; bh=9VKPKi/fD0l3iDJlaXeAIalxwR4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=4DNLI8usxZsgsycbBikWEuADJdcqyxIXy9V84uMixRFEPnVTT160RrwCmUCw4H3yf ojrOKkYRWJWVZaeq/0Nn7Gwph9wuu83dYdWK3gFJV4CYQ6Ekz02hJt9ojqFnJgz2EA 2SrZqlxbHpTO0fDdSskxhRe8VLXP/D6jdUZVHQz8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: Date: Fri, 14 Feb 2014 15:01:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3DEC4213-8D0B-488C-AD90-9B26ED2F661E@delong.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Sander Steffann X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 14 Feb 2014 15:01:14 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/nZ6KUehvu6_q1Bi257mqNWGt3yM X-Mailman-Approved-At: Sun, 16 Feb 2014 08:47:26 -0800 Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:02:41 -0000 On Feb 14, 2014, at 12:13 PM, Sander Steffann = wrote: > Hi, >=20 >>> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >>> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >>> 2014-02-12 >>=20 >> please no. if you can not assign a unique four octet integer to each >> router in your network, then you have much bigger problems. and = adding >> a capability and more complexity to try to patch over your inability = to >> configure your routers will just compound your problems. >=20 > I agree. It's a shame that the router-id looks like an IPv4 address = and IPv4 addresses are used to auto-configure it when the operator = doesn't explicitly set it. There are too many people that think that a = router-id is more than a 32-bit number and must be an IPv4 address, but = creating more complexity to avoid educating router operators isn't the = answer=85 +1 Owen From nobody Sun Feb 16 08:47:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6F91A01AC; Sat, 15 Feb 2014 03:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uop_LtO1jfNz; Sat, 15 Feb 2014 03:15:28 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id A720B1A013B; Sat, 15 Feb 2014 03:15:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id C03A737; Sat, 15 Feb 2014 12:15:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi4zyrteE+oJ; Sat, 15 Feb 2014 12:15:22 +0100 (CET) Received: from [IPv6:2a00:8640:1::c9aa:fdd:8b14:c42a] (unknown [IPv6:2a00:8640:1:0:c9aa:fdd:8b14:c42a]) by mail.sintact.nl (Postfix) with ESMTPSA id 6910034; Sat, 15 Feb 2014 12:15:21 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> Date: Sat, 15 Feb 2014 12:15:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <786C4EB0-B9FD-4A49-8F9E-B5A88CE91F76@steffann.nl> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/IJWa3rP7TqIJUBGMw04H-hlh2XI X-Mailman-Approved-At: Sun, 16 Feb 2014 08:47:26 -0800 Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 11:15:31 -0000 Op 15 feb. 2014, om 04:58 heeft Shane Amante het = volgende geschreven: > I would take exception to a ROUTER_ID being just a 32-bit integer. = Specifically, when a ROUTER_ID is an IP address that allows an operator = to quickly perform diagnosis & troubleshooting using = ping/traceroute/etc. to identify the availability and location within = the topology of the router purporting to have said ROUTER_ID. If you try to ping a router-id then all bets are off. I have seen too = many cases with misconfigured router-ids to attach any value (except the = numerical one) to them. I also never try to ping OSPF area numbers ;) > The other question I would raise is, in a far-off future, if we ever = manage to get networks converted away from dual-stack and back to a = single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you = lose those capabilities mentioned above ... would you care? Not at all. And it I wanted to link IPv6 loopback addresses and = router-ids I probably would choose a router-id (say aaa.bbb.ccc.ddd) and = then use either 2001:db8::aaa.bbb.ccc.ddd/128 or = 2001:db8::aaa:bbb:ccc:ddd/128 as loopback address. Cheers, Sander From nobody Sun Feb 16 08:47:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CA31A0073; Sat, 15 Feb 2014 07:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEK8B2I-Dgtw; Sat, 15 Feb 2014 07:26:18 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 849801A002C; Sat, 15 Feb 2014 07:26:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id BEB1B37; Sat, 15 Feb 2014 16:26:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBxUYtsQyfhX; Sat, 15 Feb 2014 16:26:12 +0100 (CET) Received: from [IPv6:2a00:8640:1::b0e8:569d:2551:8a57] (unknown [IPv6:2a00:8640:1:0:b0e8:569d:2551:8a57]) by mail.sintact.nl (Postfix) with ESMTPSA id D975934; Sat, 15 Feb 2014 16:26:11 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> Date: Sat, 15 Feb 2014 16:26:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/LpbkuLRUl_Zch3---CkJdjD5xrw X-Mailman-Approved-At: Sun, 16 Feb 2014 08:47:26 -0800 Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 15:26:20 -0000 Op 15 feb. 2014, om 16:13 heeft Shane Amante het = volgende geschreven: > On Feb 15, 2014, at 12:55 AM, Randy Bush wrote: >> I use this funny thing called DNS.=20 >=20 > And that has what to do with the problem of determining liveness or = determining where in the topology is a ROUTER_ID? And what does an integer called ROUTER_ID tell you about that? And hey, you can always create records like 1.2.3.4.router-id.castlepoint.net IN CNAME = router1.somewhere.castlepoint.net :-) Cheers, Sander From nobody Sun Feb 16 08:47:36 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26F81A0112; Sat, 15 Feb 2014 12:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWDdaiAZKNSv; Sat, 15 Feb 2014 12:58:23 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 16F311A02FA; Sat, 15 Feb 2014 12:58:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 79ADB37; Sat, 15 Feb 2014 21:58:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo31xammLCOz; Sat, 15 Feb 2014 21:58:18 +0100 (CET) Received: from [IPv6:2a00:8640:1::b0e8:569d:2551:8a57] (unknown [IPv6:2a00:8640:1:0:b0e8:569d:2551:8a57]) by mail.sintact.nl (Postfix) with ESMTPSA id 6B0C734; Sat, 15 Feb 2014 21:58:18 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> Date: Sat, 15 Feb 2014 21:58:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7596C74C-5DE5-4B44-BDCD-32AD755DF37E@steffann.nl> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/iilHNjrQ9lTCjkP2bSPzHDEi5z0 X-Mailman-Approved-At: Sun, 16 Feb 2014 08:47:26 -0800 Cc: Shane Amante , V6 Ops List , idr wg Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 20:58:24 -0000 Hi David, > As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205. = Then you can use an IPv6 loopback address of 2001:db8:1::c000:205, or = you could even used mixed notation 2001:db8:1::192.0.2.5. >=20 > So, you do not loose the ability to "quickly perform diagnosis & = troubleshooting using ping/traceroute/etc. to identify the availability = and location within the topology." Yeah, this sounds about right :) > There was also a DNS recommendation made in the thread, that would = work too. >=20 > So, I'd prefer effort be put toward an informational draft suggesting = operational practices and maybe implementation suggestions that = reinforce these suggestions rather than complicated protocol changes. =20= I fully agree. I'd be willing to help write such a draft. Cheers, Sander From nobody Sun Feb 16 08:47:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848E81A02F1; Sat, 15 Feb 2014 13:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkHFeUZfyyiE; Sat, 15 Feb 2014 13:43:02 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6691A02B6; Sat, 15 Feb 2014 13:43:01 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1FLeBem010469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 15 Feb 2014 13:40:13 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1FLeBem010469 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392500415; bh=py+2a5F2SF2/mXtnmOvVVLK8uBY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HnCAPca9T8TdpORsaTKLKyj2a4qz0KZKzDnt0wD7rov8tLJlYSPwwnWqGOYqhLQvw 8qrhS/SBU2u1gKKU+guv49kFNTXZSVxSebz+tBMaYEO7i1rkWZ3Cf+gI50k+c2gbhn HDxLstDfHapIL2l8lJe5ecysHEmXtOv1jQrl8rgY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <52FFB6B7.4090408@foobar.org> Date: Sat, 15 Feb 2014 13:31:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5E674C4B-E339-4622-88A1-254797721C1A@delong.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> <52FFB6B7.4090408@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 15 Feb 2014 13:40:15 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/02fNoQJcaNa0fbWEsD9facRzgNk X-Mailman-Approved-At: Sun, 16 Feb 2014 08:47:26 -0800 Cc: Shane Amante , V6 Ops List , Sander Steffann , draft-fan-idr-ipv6-bgp-id@tools.ietf.org, idr wg Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 21:43:04 -0000 If nothing else, if the authors intend to apply this to more routing = protocols than just BGP, they should change the proposal to reflect that = they seek to change ROUTER-IDs in general and not just the BGP = identifier. However, I believe that the idea of converting a router-id from 32 bits = to 128 bits is woefully misguided. I say this as an operator who has = operated IPv4 and IPv6 and dual-stack networks. It has always, IMHO, been unfortunate that OSPF Area numbers and = Router-IDs for various protocols have been tied to IPv4 address syntax = and, in the case of router-IDs, affiliated with interface (including = loopback) IP addresses. This has created no end of confusion among less = well trained operators. IPv6 gives us the opportunity to correct this problem and have IDs which = no longer match addresses. That is a "good thing=99" IMHO. As near as I can tell, this draft seeks to prevent that improvement from = occurring. Instead, I think that Sander and David are on a much better track and I = would be willing to join in on the efforts to write such an operational = draft. Owen On Feb 15, 2014, at 10:49 , Nick Hilliard wrote: > On 15/02/2014 15:26, Sander Steffann wrote: >> Op 15 feb. 2014, om 16:13 heeft Shane Amante = het volgende geschreven: >>> On Feb 15, 2014, at 12:55 AM, Randy Bush wrote: >>>> I use this funny thing called DNS.=20 >>>=20 >>> And that has what to do with the problem of determining liveness or = determining where in the topology is a ROUTER_ID? >>=20 >> And what does an integer called ROUTER_ID tell you about that? >>=20 >> And hey, you can always create records like >> 1.2.3.4.router-id.castlepoint.net IN CNAME = router1.somewhere.castlepoint.net >=20 > guys, we're all having a bit of an ietf moment here: within the space = of 48 > hours, the conversation has ratholed. Let's love up a bit. >=20 > The authors of the draft have a simple operational desire to make = their > lives a little easier and as an operator I sympathise with this, > particularly because they are using ipv6-only networks in anger which = is > more than I do. >=20 > There are two advantages of having a 128 bit router-id (with the = unstated > convention of tying router-id =3D=3D address of first loopback): >=20 > - firstly it's easy to identify the location of prefix announcements = on > your network > - secondly the router-id can be autoconfigured. >=20 > On the other hand, implementing this will require that the authors = define a > transition mechanism to allow 128 bit router-id routers interoperate = with > 32 bit router-id routers in such a way that router-id collisions don't = occur. >=20 > If the authors want to progress this, they need to state a stronger = use > case and they need to create a transition mechanism. If they can do = this > in a reasonable way which doesn't break backwards compatibility, then = it > might be appropriate for idr / v6ops / etc to take another look at the = draft. >=20 > Also, I wish them well because everyone understands what a router ID = is and > everyone will want to paint theirs a different colour. >=20 > Nick >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Feb 16 17:45:23 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858C61A02C3; Sun, 16 Feb 2014 17:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuEMRZqa3InQ; Sun, 16 Feb 2014 17:45:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6E11A020F; Sun, 16 Feb 2014 17:45:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFDGj-0000Vu-7k; Mon, 17 Feb 2014 01:45:14 +0000 Date: Mon, 17 Feb 2014 09:45:07 +0800 Message-ID: From: Randy Bush To: Peng Fan In-Reply-To: <006801cf2b34$22837cd0$678a7670$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> User-Agent: Wanderlust/2.15.9nreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/6PB5lKPkZk-Xvc3inxxg_p5Ibyw Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 01:45:21 -0000 > Thanks for the discussion and sorry for the late. Assigning an id is not a > difficult issue, especially on a single router. But what number is to be > assigned might be an issue, especially in an ISP's large network, in order > to guarantee the uniqueness of the ids. as i said, if you can not assign unique 32 bit integers to your routers, you have far bigger problems in your organization and network. and having them be 128 bit integers is not going to solve your problems. randy From nobody Sun Feb 16 18:51:42 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089971A0313; Sun, 16 Feb 2014 18:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99FicC5pLZpA; Sun, 16 Feb 2014 18:51:38 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 080201A02FD; Sun, 16 Feb 2014 18:51:37 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2530178ae654-3a654; Mon, 17 Feb 2014 10:49:19 +0800 (CST) X-RM-TRANSID: 2ee2530178ae654-3a654 Received: from X6X8D79D8F49E2 (unknown[10.2.52.196]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee3530178adfff-c0980; Mon, 17 Feb 2014 10:49:19 +0800 (CST) X-RM-TRANSID: 2ee3530178adfff-c0980 From: "Fan, Peng" To: "'Randy Bush'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> In-Reply-To: Date: Mon, 17 Feb 2014 10:51:26 +0800 Message-ID: <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QG64jb+AobGL2AB8SVRaJkL6d1g Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/idr/47J6-fH_IPhfb_corkFiaBj2tRc Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 02:51:41 -0000 Hi Randy, Just to clarify. I am not complaining we cannot assign the unique integers, but the integers require additional planning, and that from operational perspective causes inconvenience. Following the experience in ipv4 enabled network would be a natural thought, especially when you want the IDs to be helpful in troubleshooting rather than just pure numbers. Peng > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 17, 2014 9:45 AM > To: Peng Fan > Cc: idr wg; V6 Ops List > Subject: Re: [Idr] [v6ops] BGP Identifier > > > Thanks for the discussion and sorry for the late. Assigning an id is > > not a difficult issue, especially on a single router. But what number > > is to be assigned might be an issue, especially in an ISP's large > > network, in order to guarantee the uniqueness of the ids. > > as i said, if you can not assign unique 32 bit integers to your routers, you have far > bigger problems in your organization and network. and having them be 128 bit > integers is not going to solve your problems. > > randy From nobody Mon Feb 17 00:01:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDD91A0459 for ; Mon, 17 Feb 2014 00:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pEnff7B71gp for ; Mon, 17 Feb 2014 00:01:27 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id A0FA91A0041 for ; Mon, 17 Feb 2014 00:01:27 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 4260730007F for ; Mon, 17 Feb 2014 08:01:25 +0000 (UTC) Received: from [10.0.1.5] (c-67-188-218-56.hsd1.ca.comcast.net [67.188.218.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id C5AB730007B; Mon, 17 Feb 2014 01:01:23 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> Date: Sun, 16 Feb 2014 21:39:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1DE461CB-84D5-4D69-9825-C2134E08EA67@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Feb 17 01:01:25 2014 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 5301c1d542079716334117 X-DSPAM-Factors: 27, Mime-Version*OS+X, 0.01000, Mime-Version*X+#+#+1827, 0.01000, Cc*List+#+ietf.org, 0.01000, From*Amante+shane, 0.01000, Cc*List+v6ops, 0.01000, Cc*idr+wg, 0.01000, Subject*v6ops+BGP, 0.01000, Cc*Ops+#+v6ops, 0.01000, Mime-Version*OS+#+#+7.1, 0.01000, Cc*idr+ietf.org, 0.01000, Mime-Version*Mac+#+#+#+7.1, 0.01000, Cc*wg+#+ietf.org, 0.01000, Cc*V6+#+#+#+ietf.org, 0.01000, On+#+#+2014, 0.01000, Cc*Ops+List, 0.01000, Subject*BGP+Identifier, 0.01000, Cc*idr+#+#+ietf.org, 0.01000, Cc*V6+#+#+v6ops, 0.01000, Mime-Version*7.1+1827, 0.01000, Cc*V6+Ops, 0.01000, Mime-Version*1.0+Mac, 0.01000, From*Shane+#+shane, 0.01000, Cc*Ops+#+#+ietf.org, 0.01000, Cc*idr+#+idr, 0.01000, From*Shane Amante , 0.01000, 2014+at, 0.01000, Mime-Version*Mail+7.1, 0.01000 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/XKCpZX5jPElc5kbSIGRiBfEOrEc Cc: idr wg , V6 Ops List , Sander Steffann Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 08:01:29 -0000 Hi David, On Feb 15, 2014, at 11:25 AM, David Farmer wrote: > So, I'd prefer effort be put toward an informational draft suggesting = operational practices and maybe implementation suggestions that = reinforce these suggestions rather than complicated protocol changes. =20= I agree and would be willing to help draft text and/or review such a = draft. -shane= From nobody Mon Feb 17 01:19:20 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77E71A044D for ; Mon, 17 Feb 2014 01:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzrNwJwM9SHV for ; Mon, 17 Feb 2014 01:19:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E9B311A00B6 for ; Mon, 17 Feb 2014 01:19:13 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id BD9BC3243AE; Mon, 17 Feb 2014 10:19:10 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9626823806B; Mon, 17 Feb 2014 10:19:10 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 17 Feb 2014 10:19:10 +0100 From: To: "Bertrand Duvivier (bduvivie)" , Robert Raszuk , Pradosh Mohapatra Date: Mon, 17 Feb 2014 10:19:09 +0100 Thread-Topic: [Idr] Flowspec, coexistance of redirect and mirror actions Thread-Index: AQHOo/436d64LadntUuqPTw52t2IbJqxhuZggAixvVA= Message-ID: <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> In-Reply-To: <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810C340A30CCPUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.17.40915 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/fyAzbPLXbb_ympBob4EMQcr0W18 Cc: "mtexier@arbor.net" , "idr@ietf.org" , "ju1738@att.com" , "David Smith \(djsmith\)" , Jeff Haas Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:19:18 -0000 --_000_EEE55384044474429A926C625D0FCC810C340A30CCPUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In order to have both actions applied, why not setting twice time the extco= mmunity in the BGP update ? (one with C=3D0 and one with C=3D1). Does this cause any issue ? Applying multiple actions by setting multiple extcts seems to be authorized= , so why not using the same thing here by setting twice time the same extct= with different C flag. Otherwise need to split it in two different extcts. Thoughts ? Best Regards, Stephane De : Idr [mailto:idr-bounces@ietf.org] De la part de Bertrand Duvivier (bdu= vivie) Envoy=E9 : mardi 11 f=E9vrier 2014 21:39 =C0 : Robert Raszuk; Pradosh Mohapatra Cc : mtexier@arbor.net; idr@ietf.org; ju1738@att.com; Jeff Haas; David Smit= h (djsmith) Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi, I see 2 cases: Signaling primary/backup actions We could control path priority using LP or MED. Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ... Of N path RR could select best 2 or 3 or all best path based on preferred = LP (or MED) BGP Client could select first action, if not possible due to NH not availab= le in RIB, then act on second ... etc... Signaling multiple parallel actions. I don't have answer for this one Bertrand From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Robert Raszuk Sent: mercredi 28 ao=FBt 2013 16:52 To: Pradosh Mohapatra Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); ju1738@att.com Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi Pradosh, 5575 still requires you to run BGP best path selection even if you have mul= tiple paths. This is both for the onward advertisement as well as for the l= ocal installation. You are proposing to install more then "best" path locally which may actual= ly require substantial changes to the BGP operation. How do you control which paths are to be installed let's say which 2 out of= N ? The multipath checks are not really helpful here. It's an interesting question if we in general agree to install multiple pat= hs in flowspec SAFI for the exact same NLRI ? Regards, R. On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra > wrote: Hi Kaliraj, Suggest you use add-path: send two paths for the flow, one with next-hop X and redirect action, the other with next-hop Y and mirror action. - Pradosh ________________________________ From: Kaliraj Vairavakkalai > To: "Simpson, Adam (Adam)" >; "ju1738@att.com" >; "pmohapat@cisco.com" >; "djsmith@cisco.com" >; "H= enderickx, Wim (Wim)" >; "mtexier@arbor.net" > Cc: Jeff Haas >; "idr@ietf.org<= mailto:idr@ietf.org>" > Sent: Tuesday, August 27, 2013 10:55 AM Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI) The devices doing the scrubbing and LI may be different (based on devices' = capability, load-balancing requirement etc), was the thought behind my ques= tion. Thanks, Kaliraj > -----Original Message----- > From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] > Sent: Tuesday, August 27, 2013 10:19 AM > To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapa= t@cisco.com; > djsmith@cisco.com; Henderickx, Wim (Wim); mtexi= er@arbor.net > Cc: Jeff Haas; idr@ietf.org > Subject: Re: Flowspec, coexistance of redirect and mirror actions > > Hi Kaliraj, > > You are correct; these actions are mutually exclusive according to the cu= rrent > encoding. What does it mean for you to have a flow both moved > (redirected) and copied (mirrored)? Do you mean the original flow with > destination A is steered/moved to new destination B while at the same tim= e a > copy of this flow is sent to a new destination C? I personally have not s= een a > requirement for this type of compound action but I will leave the other > authors to comment as well. > > -Adam > > > On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" > wrote: > > >Hi authors, > > > >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > > > >If it is desired to perform both "redirect-action" to a nexthop X, and > >"mirror-action" to a different nexthop Y simultaneously for the same > >flow, how is it achieved? > > > >It appears the signaling for such a scenario may not be handled by the > >mechanisms specified in this draft, unless I am missing something. > >Could you pls clarify. > > > >Thanks > >Kaliraj > > > > _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810C340A30CCPUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

In order to have both actions applied, = why not setting twice time the extcommunity in the BGP update ? (one with C= =3D0 and one with C=3D1).

Does this cause any issue ?

 

Applying multiple actions by setting multiple extcts = seems to be authorized, so why not using the same thing here by setting twi= ce time the same extct with different C flag. Otherwise need to split it in= two different extcts.

 

Thoughts ?

 

 

Best Regar= ds,

&nbs= p;

Stephane

 

 <= /p>

De : Idr= [mailto:idr-bounces@ietf.org] De la part de Bertrand Duvivier (bduv= ivie)
Envoy=E9 : mardi 11 f=E9vrier 2014 21:39
=C0&nbs= p;: Robert Raszuk; Pradosh Mohapatra
Cc : mtexier@arbor.= net; idr@ietf.org; ju1738@att.com; Jeff Haas; David Smith (djsmith)
O= bjet : Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons

 

Hi, =

 <= /o:p>

I see 2 case= s:

<= o:p> 

Sign= aling primary/backup actions

=  

We could control path priority using LP or MED.

Assuming NLRI x PATH 1 ACT= ION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, …

 

Of N path RR could select best 2 or 3 or all = best path  based on preferred LP (or MED)

BGP Client could select first action, if = not possible due to NH not available in RIB, then act on second … etc= …

 

Signali= ng multiple parallel actions.

 

I don’t have answer for this one

=

 

Bertrand

 

 

From: idr-= bounces@ietf.org [mailto:idr-bo= unces@ietf.org] On Behalf Of Robert Raszuk
Sent: mercr= edi 28 ao=FBt 2013 16:52
To: Pradosh Mohapatra
Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); ju1738@att.com
Subject: Re: [Idr] Flo= wspec, coexistance of redirect and mirror actions

 

<= p class=3DMsoNormal>= Hi Pradosh,

 

5575 still requires you to run BGP best path selection even if yo= u have multiple paths. This is both for the onward advertisement as well as= for the local installation. 

&n= bsp;

You are proposing to install more then &qu= ot;best" path locally which may actually require substantial changes t= o the BGP operation. 

 

How do you control which paths are to be installed= let's say which 2 out of N ? The multipath checks are not really helpful h= ere. 

 

It's an interesting question if we in general agree to install mu= ltiple paths in flowspec SAFI for the exact same NLRI ? 

 

Regards,

R.

 <= /o:p>

 

&n= bsp;

 

 

 

 

On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra <mpradosh@yahoo.com> wrote:

H= i Kaliraj,

 

Suggest you use add-path: send two paths for the flow, one wit= h next-hop X 

and redirect action, the other with next-hop Y and mirror a= ction.

 

- Pradosh

 

=

From: Kali= raj Vairavakkalai <kaliraj@juniper.net>
To: "Simpson, Adam (Adam)&qu= ot; <adam.simpson@alcatel-lucent.com>; "ju1738@att.com" <ju1738@att.com>; "pmohapat@cisco.com" <= ;pmohapat@cisco.com= >; "djsm= ith@cisco.com" <djsmith@cisco.com>; "Henderickx, Wim (Wim)" <wim.he= nderickx@alcatel-lucent.com>; "mtexier@arbor.net" <mtexier@arbor.net>
Cc:= Jeff Haas <jhaas= @juniper.net>; "idr@ietf.org" <idr@ietf.org>
Sent: Tuesday, August 27, 2013 10:55 A= M
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror= actions

Yes Adam, the original flow with destination A is steered/moved to new de= stination B (e.g. scrubber device) while simultaneously copy of this flow s= ent to a new destination C (e.g. for LI)

The devices doing the scru= bbing and LI may be different (based on devices' capability, load-balancing= requirement etc), was the thought behind my question.

Thanks,
= Kaliraj
> -----Original Message-----
> From: Simpson, Adam (Ad= am) [mailto:adam.simpson@alcatel-lucent.com]
> Sent: Tuesday, August 27= , 2013 10:19 AM
> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com;
> djsmith@cisco.com; Henderickx,= Wim (Wim); mtexier@= arbor.net
> Cc: Jeff Haas; idr@ietf.org
> Subject: Re: Flowspec, coexistance of = redirect and mirror actions
>
> Hi Kaliraj,
>
> Y= ou are correct; these actions are mutually exclusive according to the curre= nt
> encoding. What does it mean for you to have a flow both moved> (redirected) and copied (mirrored)? Do you mean the original flow wit= h
> destination A is steered/moved to new destination B while at the = same time a
> copy of this flow is sent to a new destination C? I per= sonally have not seen a
> requirement for this type of compound actio= n but I will leave the other
> authors to comment as well.
> > -Adam
>
>
> On 2013-08-25 1:13 AM, "Kaliraj= Vairavakkalai" <kaliraj@juniper.net> wrote:
>
> >Hi authors,<= br>> >
> >Ref: http://tools.ietf.org/ht= ml/draft-simpson-idr-flowspec-redirect-02
> >
> >If i= t is desired to perform both "redirect-action" to a nexthop X, an= d
> >"mirror-action" to a different nexthop Y simultaneo= usly for the same
> >flow, how is it achieved?
> >
>= ; >It appears the signaling for such a scenario may not be handled by th= e
> >mechanisms specified in this draft, unless I am missing somet= hing.
> >Could you pls clarify.
> >
> >Thanks> >Kaliraj
> >
>
>


_______________= ________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailma= n/listinfo/idr


_______________________________________________
Idr mailing list<= br>Idr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/idr

 

_______________=
___________________________________________________________________________=
_______________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC810C340A30CCPUEXCB2Fnante_-- From nobody Mon Feb 17 01:25:00 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDD91A045B; Mon, 17 Feb 2014 01:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVJp94NiWsDM; Mon, 17 Feb 2014 01:24:56 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7911A03A6; Mon, 17 Feb 2014 01:24:56 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hr17so10884731lab.20 for ; Mon, 17 Feb 2014 01:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yyEj7d47DDcyide0T1UhIFvCBHPW20RF9QCadId4EBs=; b=dy+hZvxJ13JF81yMwTGHNd/SbI/jPR8tmiForHDgcSDvOes/fH7ZlK9zmPRdQen5xa fhv7HEirlo67Q41Cd9foMqahQzuq4Nqq9Nft+f6J4Be00eW/stZRtj94OuesAK3Ws3W+ loM6ea/0yxMVzJyZdFYeind7ovAYnVbLoazC1OmCni57ALmWqPQWEdHk2G2OjBkMcWN7 PszjVAyEwVYLaHFrhrNxuOEbLoDiZTM+JSQVAGPYS25SXJNPO+rC7ADHPJyxzuFF7vxw 6slxLDUqbLOzdn58YCtwDpfycmHE2CTUh1C1yJb1ISQ8CGOeKSibyOCnTtIKMOL+bn4F CuKw== MIME-Version: 1.0 X-Received: by 10.152.27.133 with SMTP id t5mr130498lag.66.1392629093052; Mon, 17 Feb 2014 01:24:53 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.51.105 with HTTP; Mon, 17 Feb 2014 01:24:52 -0800 (PST) In-Reply-To: <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> Date: Mon, 17 Feb 2014 10:24:52 +0100 X-Google-Sender-Auth: _ozdho1IxeT31fW6UvE8HoRaWBU Message-ID: From: Robert Raszuk To: "Fan, Peng" Content-Type: multipart/alternative; boundary=089e0160c2ce6536da04f296ba65 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/zAhc_ei9TC_hWEAtqhYFVBHQeuE Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:24:59 -0000 --089e0160c2ce6536da04f296ba65 Content-Type: text/plain; charset=ISO-8859-1 Hi Peng, Can't you just use ::a.b.c.d/96 for ping and troubleshooting 4 octet router_id in IPv6 only network? No protocol changes needed :) r. On Mon, Feb 17, 2014 at 3:51 AM, Fan, Peng wrote: > Hi Randy, > > Just to clarify. I am not complaining we cannot assign the unique integers, > but the integers require additional planning, and that from operational > perspective causes inconvenience. Following the experience in ipv4 enabled > network would be a natural thought, especially when you want the IDs to be > helpful in troubleshooting rather than just pure numbers. > > Peng > > > -----Original Message----- > > From: Randy Bush [mailto:randy@psg.com] > > Sent: Monday, February 17, 2014 9:45 AM > > To: Peng Fan > > Cc: idr wg; V6 Ops List > > Subject: Re: [Idr] [v6ops] BGP Identifier > > > > > Thanks for the discussion and sorry for the late. Assigning an id is > > > not a difficult issue, especially on a single router. But what number > > > is to be assigned might be an issue, especially in an ISP's large > > > network, in order to guarantee the uniqueness of the ids. > > > > as i said, if you can not assign unique 32 bit integers to your routers, > you have far > > bigger problems in your organization and network. and having them be 128 > bit > > integers is not going to solve your problems. > > > > randy > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --089e0160c2ce6536da04f296ba65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Peng,

= Can't you just use=A0::a.= b.c.d/96 for ping and troubleshooting 4 octet router_id in IPv6 only networ= k?=A0

No protocol changes needed :)=

r.


On Mon,= Feb 17, 2014 at 3:51 AM, Fan, Peng <fanpeng@chinamobile.com>= wrote:
Hi Randy,

Just to clarify. I am not complaining we cannot assign the unique integers,=
but the integers require additional planning, and that from operational
perspective causes inconvenience. Following the experience in ipv4 enabled<= br> network would be a natural thought, especially when you want the IDs to be<= br> helpful in troubleshooting rather than just pure numbers.

Peng

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.co= m]
> Sent: Monday, February 17, 2014 9:45 AM
> To: Peng Fan
> Cc: idr wg; V6 Ops List
> Subject: Re: [Idr] [v6ops] BGP Identifier
>
> > Thanks for the disc= ussion and sorry for the late. Assigning an id is
> > not a difficult issue, especially on a single router. But what nu= mber
> > is to be assigned might be an issue, especially in an ISP's l= arge
> > network, in order to guarantee the uniqueness of the ids.
>
> as i said, if you can not assign unique 32 bit integers to your router= s,
you have far
> bigger problems in your organization and network. =A0and having them b= e 128
bit
> integers is not going to solve your problems.
>
> randy



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

--089e0160c2ce6536da04f296ba65-- From nobody Mon Feb 17 02:10:36 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639D71A03C3; Mon, 17 Feb 2014 02:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CBR8jAa_Ir1; Mon, 17 Feb 2014 02:10:28 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id BF80B1A03AE; Mon, 17 Feb 2014 02:10:27 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15301df8a7cc-e37cc; Mon, 17 Feb 2014 18:08:10 +0800 (CST) X-RM-TRANSID: 2ee15301df8a7cc-e37cc Received: from X6X8D79D8F49E2 (unknown[10.2.52.196]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35301df89908-c9e11; Mon, 17 Feb 2014 18:08:10 +0800 (CST) X-RM-TRANSID: 2ee35301df89908-c9e11 From: "Fan, Peng" To: "'Robert Raszuk'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> In-Reply-To: Date: Mon, 17 Feb 2014 18:10:57 +0800 Message-ID: <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01CF2C0B.9B400440" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QG64jb+AobGL2AB8SVRaAGHMZlXAkZuM4GY7fbMQA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Afbax565RJu6hLiiybaVBQ34hqQ Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:10:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0025_01CF2C0B.9B400440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Robert, Yes that is a possible solution for troubleshooting, once the router_id has been determined. But how do you determine at first the value of a.b.c.d when there is no ipv4 address to be referred to, especially in an automatic manner? Beforehand planning work for the ids for the entire network is something I am concerned with :) Regards, Peng From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk Sent: Monday, February 17, 2014 5:25 PM To: Fan, Peng Cc: Randy Bush; idr wg; V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier Hi Peng, Can't you just use ::a.b.c.d/96 for ping and troubleshooting 4 octet router_id in IPv6 only network? No protocol changes needed :) r. On Mon, Feb 17, 2014 at 3:51 AM, Fan, Peng wrote: Hi Randy, Just to clarify. I am not complaining we cannot assign the unique integers, but the integers require additional planning, and that from operational perspective causes inconvenience. Following the experience in ipv4 enabled network would be a natural thought, especially when you want the IDs to be helpful in troubleshooting rather than just pure numbers. Peng > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 17, 2014 9:45 AM > To: Peng Fan > Cc: idr wg; V6 Ops List > Subject: Re: [Idr] [v6ops] BGP Identifier > > > Thanks for the discussion and sorry for the late. Assigning an id is > > not a difficult issue, especially on a single router. But what number > > is to be assigned might be an issue, especially in an ISP's large > > network, in order to guarantee the uniqueness of the ids. > > as i said, if you can not assign unique 32 bit integers to your routers, you have far > bigger problems in your organization and network. and having them be 128 bit > integers is not going to solve your problems. > > randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_0025_01CF2C0B.9B400440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 

Yes that is a possible solution for troubleshooting, once the = router_id has been determined. But how do you determine at first the = value of a.b.c.d when there is no ipv4 address to be referred to, = especially in an automatic manner? Beforehand planning work for the ids = for the entire network is something I am concerned with = :)

 

Regards,

Peng

 

From:= = rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: Monday, February 17, 2014 5:25 PM
To: = Fan, Peng
Cc: Randy Bush; idr wg; V6 Ops = List
Subject: Re: [Idr] [v6ops] BGP = Identifier

 

Hi Peng,

 

Can't you just use ::a.b.c.d/96 for ping and troubleshooting 4 octet = router_id in IPv6 only network? 

 

No protocol changes needed = :)

 

r.

 

On Mon, Feb 17, 2014 at 3:51 AM, Fan, Peng <fanpeng@chinamobile.com> = wrote:

Hi = Randy,

Just to clarify. I am not complaining we cannot assign the = unique integers,
but the integers require additional planning, and = that from operational
perspective causes inconvenience. Following the = experience in ipv4 enabled
network would be a natural thought, = especially when you want the IDs to be
helpful in troubleshooting = rather than just pure numbers.

Peng


> -----Original = Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Monday, = February 17, 2014 9:45 AM
> To: Peng Fan
> Cc: idr wg; V6 = Ops List
> Subject: Re: [Idr] [v6ops] BGP = Identifier
>

> > Thanks for the discussion = and sorry for the late. Assigning an id is
> > not a difficult = issue, especially on a single router. But what number
> > is to = be assigned might be an issue, especially in an ISP's large
> > = network, in order to guarantee the uniqueness of the = ids.
>
> as i said, if you can not assign unique 32 bit = integers to your routers,
you have far
> bigger problems in = your organization and network.  and having them be = 128
bit
> integers is not going to solve your = problems.
>
> = randy



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

 

------=_NextPart_000_0025_01CF2C0B.9B400440-- From nobody Mon Feb 17 02:13:29 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E881A045B for ; Mon, 17 Feb 2014 02:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We5X5ySxRZ9P for ; Mon, 17 Feb 2014 02:13:25 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7BD1A0453 for ; Mon, 17 Feb 2014 02:13:25 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D235F62EED for ; Mon, 17 Feb 2014 11:13:21 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A263962EDC for ; Mon, 17 Feb 2014 11:13:21 +0100 (CET) Received: (qmail 24575 invoked by uid 1007); 17 Feb 2014 11:13:21 +0100 Date: Mon, 17 Feb 2014 11:13:21 +0100 From: Gert Doering To: "Fan, Peng" Message-ID: <20140217101321.GI75390@Space.Net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/aG7RsJDUhqE3AZIIYbfOCT7vCNU Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:13:27 -0000 Hi, On Mon, Feb 17, 2014 at 06:10:57PM +0800, Fan, Peng wrote: > Yes that is a possible solution for troubleshooting, once the router_id has > been determined. But how do you determine at first the value of a.b.c.d when > there is no ipv4 address to be referred to, especially in an automatic > manner? Beforehand planning work for the ids for the entire network is > something I am concerned with :) How do you plan transit network and loopback IP assignment? See, it's quite doable. (Assign loopback addresses in a way that you can use the last 32 bits as router ID, done) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Feb 17 02:25:55 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0C21A03C3; Mon, 17 Feb 2014 02:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJojVpsLArH4; Mon, 17 Feb 2014 02:25:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id BB78F1A00DD; Mon, 17 Feb 2014 02:25:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFLOQ-00024C-SU; Mon, 17 Feb 2014 10:25:43 +0000 Date: Mon, 17 Feb 2014 18:25:40 +0800 Message-ID: From: Randy Bush To: "Fan, Peng" In-Reply-To: <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Zmavnnb08ASdurkrqvJQaB5ULc0 Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:25:50 -0000 > Yes that is a possible solution for troubleshooting, once the router_id has > been determined. But how do you determine at first the value of a.b.c.d when > there is no ipv4 address to be referred to, especially in an automatic > manner? Beforehand planning work for the ids for the entire network is > something I am concerned with :) all your comments are symptoms of the insanity of trying to configure a large network manually. this went out of fashion in the last century, and we do not try to compensate for insanity through protocol modification. randy From nobody Mon Feb 17 06:16:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3C51A04E6; Mon, 17 Feb 2014 06:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zjh76SfcEl3H; Mon, 17 Feb 2014 06:15:56 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id CBF551A04FB; Mon, 17 Feb 2014 06:15:54 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25302190dee3-45ee3; Mon, 17 Feb 2014 22:13:34 +0800 (CST) X-RM-TRANSID: 2ee25302190dee3-45ee3 Received: from X6X8D79D8F49E2 (unknown[125.97.45.50]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15302190c128-0b7cb; Mon, 17 Feb 2014 22:13:34 +0800 (CST) X-RM-TRANSID: 2ee15302190c128-0b7cb From: "Fan, Peng" To: "'Gert Doering'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> <20140217101321.GI75390@Space.Net> In-Reply-To: <20140217101321.GI75390@Space.Net> Date: Mon, 17 Feb 2014 22:16:00 +0800 Message-ID: <009701cf2bea$c939be20$5bad3a60$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QG64jb+AobGL2AB8SVRaAGHMZlXAkZuM4ECPpt9WQLDsJzGmMYV8zA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/idr/p_AWtnnwSUx9CDFbwo10LAkcg4I Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:15:59 -0000 Hi Gert, I see your point. We use a hierarchy in operating a large network, for example the headquarter assigns an address block to a province, and the province assigns a sub-block to a city, and administrators in the city assigns an address to a router. We cannot require an admin to assign an address with a unique id as they don't know what others use for ids. Operating the entire network by a single person would be easy but we can rarely see this case. Peng > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, February 17, 2014 6:13 PM > To: Fan, Peng > Cc: 'Robert Raszuk'; 'idr wg'; 'V6 Ops List' > Subject: Re: [v6ops] [Idr] BGP Identifier > > Hi, > > On Mon, Feb 17, 2014 at 06:10:57PM +0800, Fan, Peng wrote: > > Yes that is a possible solution for troubleshooting, once the > > router_id has been determined. But how do you determine at first the > > value of a.b.c.d when there is no ipv4 address to be referred to, > > especially in an automatic manner? Beforehand planning work for the > > ids for the entire network is something I am concerned with :) > > How do you plan transit network and loopback IP assignment? > > See, it's quite doable. > > (Assign loopback addresses in a way that you can use the last 32 bits as router ID, > done) > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Feb 17 06:16:09 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B451A0503; Mon, 17 Feb 2014 06:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E8N2MqsIabO; Mon, 17 Feb 2014 06:15:58 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id CF39F1A04FF; Mon, 17 Feb 2014 06:15:54 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee253021913eea-45eea; Mon, 17 Feb 2014 22:13:40 +0800 (CST) X-RM-TRANSID: 2ee253021913eea-45eea Received: from X6X8D79D8F49E2 (unknown[125.97.45.50]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35302191057b-ce04c; Mon, 17 Feb 2014 22:13:40 +0800 (CST) X-RM-TRANSID: 2ee35302191057b-ce04c From: "Fan, Peng" To: "'Randy Bush'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> In-Reply-To: Date: Mon, 17 Feb 2014 22:16:07 +0800 Message-ID: <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QG64jb+AobGL2AB8SVRaAGHMZlXAkZuM4ECPpt9WQLwciK2mMS/IJA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Nd6PeSooEOmitUfFuoHs4aFTn8g Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:16:05 -0000 Randy, Would you please give me an example about how modern large ISPs manage their networks? > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 17, 2014 6:26 PM > To: Fan, Peng > Cc: 'Robert Raszuk'; 'idr wg'; 'V6 Ops List' > Subject: Re: [Idr] [v6ops] BGP Identifier > > > Yes that is a possible solution for troubleshooting, once the > > router_id has been determined. But how do you determine at first the > > value of a.b.c.d when there is no ipv4 address to be referred to, > > especially in an automatic manner? Beforehand planning work for the > > ids for the entire network is something I am concerned with :) > > all your comments are symptoms of the insanity of trying to configure a large > network manually. this went out of fashion in the last century, and we do not > try to compensate for insanity through protocol modification. > > randy From nobody Mon Feb 17 06:50:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640D31A0503; Mon, 17 Feb 2014 06:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTmyIYnwPwFx; Mon, 17 Feb 2014 06:50:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 12BB51A0209; Mon, 17 Feb 2014 06:50:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFPWX-0000pc-BS; Mon, 17 Feb 2014 14:50:22 +0000 Date: Mon, 17 Feb 2014 22:50:18 +0800 Message-ID: From: Randy Bush To: "Fan, Peng" In-Reply-To: <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/WYXTXT_aAYyyzywLoOYXQJGSOfY Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:50:29 -0000 > Would you please give me an example about how modern large ISPs manage their > networks? programmatic generation of configurations from databases. randy From nobody Mon Feb 17 07:53:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679C71A0502; Mon, 17 Feb 2014 07:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxV09VfoIYPE; Mon, 17 Feb 2014 07:53:49 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 818091A0507; Mon, 17 Feb 2014 07:53:49 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id b8032035.2ac0d0052940.2848596.00-2437.7947596.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 15:53:47 +0000 (UTC) X-MXL-Hash: 5302308b42ac272f-7ef366ae0b5dc6619311f68523019213c1665cb8 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id d6032035.0.2848356.00-2179.7946900.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 15:53:18 +0000 (UTC) X-MXL-Hash: 5302306e628e96f1-88ebdcbe81aed40c2e5a9316f523ae7dd22fc697 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HFrGDv003001; Mon, 17 Feb 2014 10:53:16 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HFr7cC002787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 10:53:12 -0500 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 17 Feb 2014 15:52:55 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 10:52:54 -0500 From: "UTTARO, JAMES" To: Randy Bush , "Fan, Peng" Thread-Topic: [Idr] [v6ops] BGP Identifier Thread-Index: AQHPK4HukH+sv9yQ+kSGj1ZIvBEoEZq5ExoAgABt7ACAAAzhgIAABBwAgAAHYcA= Date: Mon, 17 Feb 2014 15:52:53 +0000 Message-ID: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.53.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=Ml6WOlLKuc4A:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=e_BCuZGg8] X-AnalysisOut: [NsA:10 a=48vgC7mUAAAA:8 a=yyzX4cs7Mzi1HQJBC4AA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=WEfm6-8eHTEN4XfZ:21 a=IFZ0Xh6] X-AnalysisOut: [NAL3Oz8jK:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/JM6c2rMxrPnjbeHwq70ni4qVQJ8 Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:53:51 -0000 We endeavor to automate as much as possible as manual/human manipulation us= ually results in a big error at some point.. Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Monday, February 17, 2014 5:26 AM To: Fan, Peng Cc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier > Yes that is a possible solution for troubleshooting, once the router_id h= as > been determined. But how do you determine at first the value of a.b.c.d w= hen > there is no ipv4 address to be referred to, especially in an automatic > manner? Beforehand planning work for the ids for the entire network is > something I am concerned with :) all your comments are symptoms of the insanity of trying to configure a large network manually. this went out of fashion in the last century, and we do not try to compensate for insanity through protocol modification. randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Feb 17 07:59:59 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D1B1A03D2; Mon, 17 Feb 2014 07:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgYBXUeJEO21; Mon, 17 Feb 2014 07:59:55 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2101A022E; Mon, 17 Feb 2014 07:59:55 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hr17so11388842lab.34 for ; Mon, 17 Feb 2014 07:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qOg25b84tv23NsrWm0J+cA8WIXJCWhmBtBifp+CXfSw=; b=BBmqz5JQ4cV4ko+ngmjh+jniK9K4tVc2ZXLnorBwqhSCDfnPTDEdiIua6Cd7G4XzmD ZCCZCWSnOV4FBzt9ckDnYkkbtIWxo5w+RMC0ZJPaiKLYlBeHGcbf1whS1qR4YG2odelB wfmM3xcTYzfcQf5riwM5X3ZvY/cApgA4Iqc//mxOvEP7K7++3FYnV1etoFoWZ15Hunys MwSDcvzBiYTN6IdUgHB/UOOxD2/AqIWyBGBfMsLlV8pURkHLChI/iI9jL5i8lqP5T6yp q/9C2DsF9ZsDI/++XSZKPkgXoqcxmHxYdjaY/pNF89NUQ5VjQhSZgz+wb3BJ0prkRXlT KP7g== MIME-Version: 1.0 X-Received: by 10.152.207.37 with SMTP id lt5mr25143lac.90.1392652791770; Mon, 17 Feb 2014 07:59:51 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.152.203.167 with HTTP; Mon, 17 Feb 2014 07:59:51 -0800 (PST) In-Reply-To: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> Date: Mon, 17 Feb 2014 10:59:51 -0500 X-Google-Sender-Auth: qEuZZACTHTb-pt1Uz43LiFphlcg Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Prl0dmFR5k60gqBZzrEd80pBB-k Cc: idr wg , V6 Ops List , Robert Raszuk Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:59:57 -0000 http://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf Mike's presentation (given by vijay) is a decent start... On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush wrote: >> Would you please give me an example about how modern large ISPs manage their >> networks? > > programmatic generation of configurations from databases. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Feb 17 12:28:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894031A04E5; Mon, 17 Feb 2014 12:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVmZ69kfcpH2; Mon, 17 Feb 2014 12:28:34 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C3E721A04D2; Mon, 17 Feb 2014 12:28:34 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1HKSTlG052575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 20:28:30 GMT (envelope-from joelja@bogus.com) Message-ID: <530270E8.5090603@bogus.com> Date: Mon, 17 Feb 2014 12:28:24 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: David Farmer , Shane Amante References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> In-Reply-To: <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p6sDx158VsAp83MjGOIW8Tnpfjwd1SI67" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 17 Feb 2014 20:28:30 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/OGbJRsQ3cljGjc_n2airdA1MHJg Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 20:28:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p6sDx158VsAp83MjGOIW8Tnpfjwd1SI67 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/15/14, 11:25 AM, David Farmer wrote: > As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205. > Then you can use an IPv6 loopback address of 2001:db8:1::c000:205, or > you could even used mixed notation 2001:db8:1::192.0.2.5. You could, but you shouldn't whether it's merely shorthand or not because ipv6 mapped ipv4 addresses and accompanying notation are are sort of ugly representation that will be throwing junior network operators under the bus for years to come. http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00 --p6sDx158VsAp83MjGOIW8Tnpfjwd1SI67 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMCcOgACgkQ8AA1q7Z/VrLAzQCcCH4yqWdYtyWH7ldCuon32yn/ BnEAniES0Cc636YqsXpQZ0Dq6MC3Gz1B =XYHJ -----END PGP SIGNATURE----- --p6sDx158VsAp83MjGOIW8Tnpfjwd1SI67-- From nobody Mon Feb 17 13:34:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD11A0295 for ; Mon, 17 Feb 2014 13:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VTG-wWsT6YZ for ; Mon, 17 Feb 2014 13:34:04 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CE6BC1A028F for ; Mon, 17 Feb 2014 13:34:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31169; q=dns/txt; s=iport; t=1392672841; x=1393882441; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qF0+1FUZswUCjRqWaLMTG3155zAFiY5C3s4gNgYTe7A=; b=XVYoQ7MIjRMkyYL2eYhkcYy5KR0K8RlRqmpS6VZFG/GvCwIEk2Z9ze7I xNTpYNxO1D/kv/ANap4ucWMtZDbZWht6oNhC1fsg+o9WzJeRcbSWFatB7 hG8zxydEZEPTILmaukz5ZWF0pCkhJu+jg6rssZL6bZiYCbyXC1lG6ADf6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0GAKV/AlOtJXG8/2dsb2JhbABZgkJEOFeqN4w4iFmBIRZ0giUBAQEEAQEBKkELDAQCAQgRBAEBAQoWAQYHJwsTAQkIAgQBDQUIh2kDEQ3KRReMZ4EvCREBHx8IBQEEBgEGgx6BFASJEIszggODGIsshUWDLYFxOQ X-IronPort-AV: E=Sophos;i="4.95,863,1384300800"; d="scan'208,217";a="304625677" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 17 Feb 2014 21:34:00 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1HLXxGc005570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 21:33:59 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.119]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 15:33:59 -0600 From: "Saikat Ray (sairay)" To: "stephane.litkowski@orange.com" , "Bertrand Duvivier (bduvivie)" , Robert Raszuk , Pradosh Mohapatra Thread-Topic: [Idr] Flowspec, coexistance of redirect and mirror actions Thread-Index: AQHOo/436d64LadntUuqPTw52t2IbJqxhuZggAixvVCAAM664A== Date: Mon, 17 Feb 2014 21:33:59 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A11B2B080@xmb-rcd-x13.cisco.com> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.165.99] Content-Type: multipart/alternative; boundary="_000_8ED5B0B0F5B4854A912480C1521F973A11B2B080xmbrcdx13ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/3sAa7LEhmKtQsnqQGFKZRDDsceE Cc: "mtexier@arbor.net" , "idr@ietf.org" , "ju1738@att.com" , "David Smith \(djsmith\)" , Jeff Haas Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 21:34:16 -0000 --_000_8ED5B0B0F5B4854A912480C1521F973A11B2B080xmbrcdx13ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A given update (a BGP path) has only one NEXTHOP (the NEXTHOP determines wh= ere to redirect or mirror the packets). From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@ora= nge.com Sent: Monday, February 17, 2014 1:19 AM To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra Cc: mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith (djsmith);= Jeff Haas Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi, In order to have both actions applied, why not setting twice time the extco= mmunity in the BGP update ? (one with C=3D0 and one with C=3D1). Does this cause any issue ? Applying multiple actions by setting multiple extcts seems to be authorized= , so why not using the same thing here by setting twice time the same extct= with different C flag. Otherwise need to split it in two different extcts. Thoughts ? Best Regards, Stephane De : Idr [mailto:idr-bounces@ietf.org] De la part de Bertrand Duvivier (bdu= vivie) Envoy=E9 : mardi 11 f=E9vrier 2014 21:39 =C0 : Robert Raszuk; Pradosh Mohapatra Cc : mtexier@arbor.net; idr@ietf.org; ju1738@att.com; Jeff Haas; David Smith (dj= smith) Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi, I see 2 cases: Signaling primary/backup actions We could control path priority using LP or MED. Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ... Of N path RR could select best 2 or 3 or all best path based on preferred = LP (or MED) BGP Client could select first action, if not possible due to NH not availab= le in RIB, then act on second ... etc... Signaling multiple parallel actions. I don't have answer for this one Bertrand From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Robert Raszuk Sent: mercredi 28 ao=FBt 2013 16:52 To: Pradosh Mohapatra Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); ju1738@att.com Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi Pradosh, 5575 still requires you to run BGP best path selection even if you have mul= tiple paths. This is both for the onward advertisement as well as for the l= ocal installation. You are proposing to install more then "best" path locally which may actual= ly require substantial changes to the BGP operation. How do you control which paths are to be installed let's say which 2 out of= N ? The multipath checks are not really helpful here. It's an interesting question if we in general agree to install multiple pat= hs in flowspec SAFI for the exact same NLRI ? Regards, R. On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra > wrote: Hi Kaliraj, Suggest you use add-path: send two paths for the flow, one with next-hop X and redirect action, the other with next-hop Y and mirror action. - Pradosh ________________________________ From: Kaliraj Vairavakkalai > To: "Simpson, Adam (Adam)" >; "ju1738@att.com" >; "pmohapat@cisco.com" >; "djsmith@cisco.com" >; "H= enderickx, Wim (Wim)" >; "mtexier@arbor.net" > Cc: Jeff Haas >; "idr@ietf.org<= mailto:idr@ietf.org>" > Sent: Tuesday, August 27, 2013 10:55 AM Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI) The devices doing the scrubbing and LI may be different (based on devices' = capability, load-balancing requirement etc), was the thought behind my ques= tion. Thanks, Kaliraj > -----Original Message----- > From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] > Sent: Tuesday, August 27, 2013 10:19 AM > To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapa= t@cisco.com; > djsmith@cisco.com; Henderickx, Wim (Wim); mtexi= er@arbor.net > Cc: Jeff Haas; idr@ietf.org > Subject: Re: Flowspec, coexistance of redirect and mirror actions > > Hi Kaliraj, > > You are correct; these actions are mutually exclusive according to the cu= rrent > encoding. What does it mean for you to have a flow both moved > (redirected) and copied (mirrored)? Do you mean the original flow with > destination A is steered/moved to new destination B while at the same tim= e a > copy of this flow is sent to a new destination C? I personally have not s= een a > requirement for this type of compound action but I will leave the other > authors to comment as well. > > -Adam > > > On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" > wrote: > > >Hi authors, > > > >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > > > >If it is desired to perform both "redirect-action" to a nexthop X, and > >"mirror-action" to a different nexthop Y simultaneously for the same > >flow, how is it achieved? > > > >It appears the signaling for such a scenario may not be handled by the > >mechanisms specified in this draft, unless I am missing something. > >Could you pls clarify. > > > >Thanks > >Kaliraj > > > > _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8ED5B0B0F5B4854A912480C1521F973A11B2B080xmbrcdx13ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A given update (a BGP path) = has only one NEXTHOP (the NEXTHOP determines where to redirect or mirror th= e packets).

 

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Monday, February 17, 2014 1:19 AM
To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra Cc: mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith (dj= smith); Jeff Haas
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons

 

Hi,

 

In order to have both act= ions applied, why not setting twice time the extcommunity in the BGP update= ? (one with C=3D0 and one with C=3D1).

Does this cause any issue= ?

 <= /p>

Applying multiple actions= by setting multiple extcts seems to be authorized, so why not using the sa= me thing here by setting twice time the same extct with different C flag. Otherwise need to split it in two different extcts.=

 <= /p>

Thoughts ?

 <= /p>

 <= /p>

Best Regards,<= /span>

 <= /p>

Stephane

 <= /p>

 <= /p>

De : Idr = [mailto:idr-bounces@ietf.org] De la part de Bertrand Duvivier (bduvivie)
Envoy=E9 : mardi 11 f=E9vrier 2014 21:39
=C0 : Robert Raszuk; Pradosh Mohapatra
Cc : mtexier@arbor.net= ; idr@ietf.org; ju1738@att.com; Jef= f Haas; David Smith (djsmith)
Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror = actions

 

Hi,

 <= /p>

I see 2 cases:

 <= /p>

Signaling primary/back= up actions

 <= /p>

We could control path pri= ority using LP or MED.

Assuming NLRI x PATH 1 AC= TION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, …

 <= /p>

Of N path RR could select= best 2 or 3 or all best path  based on preferred LP (or MED)

BGP Client could select f= irst action, if not possible due to NH not available in RIB, then act on se= cond … etc…

 <= /p>

Signaling multiple par= allel actions.

 <= /p>

I don’t have answer= for this one

 <= /p>

Bertrand

 <= /p>

 <= /p>

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: mercredi 28 ao=FBt 2013 16:52
To: Pradosh Mohapatra
Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); ju1738@att.com
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons

 

= Hi Pradosh,

=  

= 5575 still requires you to run BGP best path selection even if you have mul= tiple paths. This is both for the onward advertisement as well as for the l= ocal installation. 

=  

= You are proposing to install more then "best" path locally which = may actually require substantial changes to the BGP operation. 

=  

= How do you control which paths are to be installed let's say which 2 out of= N ? The multipath checks are not really helpful here. 

=  

= It's an interesting question if we in general agree to install multiple pat= hs in flowspec SAFI for the exact same NLRI ? 

=  

= Regards,

= R.

=  

=  

=  

=  

=  

=  

 

On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra = <mpradosh@yahoo.= com> wrote:

Hi Kaliraj,

 

Suggest you use add-path: send two paths for the flo= w, one with next-hop X 

and redirect action, the other with next-hop Y and m= irror action.

 

- Pradosh

 

From: Kaliraj Vairavakkalai <kaliraj@juniper.net>
To: "Simpson, Adam (Adam)" <adam.simpson@alcatel-lucent.com>; "ju1738@at= t.com" <ju1= 738@att.com>; "pmohapat@cis= co.com" <pmohapat@cisco.com>; "djsmith@cisco.com" <djsmith@cisco.com>; "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>= ;; "mtexier@arb= or.net" <mtexier@arbor.net>
Cc: Jeff Haas <jhaas@juniper.net>; "idr@ietf.org" <idr@ietf.org>
Sent: Tuesday, August 27, 2013 10:55 AM
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons


Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI)

The devices doing the scrubbing and LI may be different (based on devices' = capability, load-balancing requirement etc), was the thought behind my ques= tion.

Thanks,
Kaliraj
> -----Original Message-----
> From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com]
> Sent: Tuesday, August 27, 2013 10:19 AM
> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com<= /a>;
> djsmith@cisco.c= om; Henderickx, Wim (Wim); mtexier@arbor.net
> Cc: Jeff Haas; idr@i= etf.org
> Subject: Re: Flowspec, coexistance of redirect and mirror actions
>
> Hi Kaliraj,
>
> You are correct; these actions are mutually exclusive according to the= current
> encoding. What does it mean for you to have a flow both moved
> (redirected) and copied (mirrored)? Do you mean the original flow with=
> destination A is steered/moved to new destination B while at the same = time a
> copy of this flow is sent to a new destination C? I personally have no= t seen a
> requirement for this type of compound action but I will leave the othe= r
> authors to comment as well.
>
> -Adam
>
>
> On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" <kaliraj@juniper.net&g= t; wrote:
>
> >Hi authors,
> >
> >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02
> >
> >If it is desired to perform both "redirect-action" to a = nexthop X, and
> >"mirror-action" to a different nexthop Y simultaneously = for the same
> >flow, how is it achieved?
> >
> >It appears the signaling for such a scenario may not be handled by= the
> >mechanisms specified in this draft, unless I am missing something.=
> >Could you pls clarify.
> >
> >Thanks
> >Kaliraj
> >
>
>


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


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

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_8ED5B0B0F5B4854A912480C1521F973A11B2B080xmbrcdx13ciscoc_-- From nobody Mon Feb 17 13:45:44 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778461A0408 for ; Mon, 17 Feb 2014 13:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMVGuesk2gnK for ; Mon, 17 Feb 2014 13:45:38 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 839B81A02E2 for ; Mon, 17 Feb 2014 13:45:37 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id b8so11516993lan.5 for ; Mon, 17 Feb 2014 13:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jjWQ1criTEIaXyrx3m5WfxiVB7TEp6XmT9cGg16yCag=; b=bQ3sSnaM4QboeE8xYOQi/GLyy7+CTpRgSYaX2OEyMl4LritjOyJgcAp0//4hTd0Faa qvc1TA3ua5grwUon3OIZ5gY6EpaVcwnD87ACNQZquzaDiYhzN/iCGZw2atluybiD74iK 3dBpF+fzX0eawU0shLxt/lh6FlCxIpb0g/DK6iM3zVN50nAvjksqR1+30iuDPYz1Kcyd oaZG99RhLILw2gfg9rv3WOvEd7hrQix9GGgZLUJBP3dy/fIn7Ve0eBnci9c+j9nM+t3x 4MFqDkDy+j50tPvVXk+zUCF0+oL45IQMYr0aThOf7sC7xNfjyAJ00Ekfb7UztXNKZ7Ma EWaw== MIME-Version: 1.0 X-Received: by 10.112.40.114 with SMTP id w18mr18073641lbk.20.1392673534174; Mon, 17 Feb 2014 13:45:34 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.51.105 with HTTP; Mon, 17 Feb 2014 13:45:34 -0800 (PST) In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A11B2B080@xmb-rcd-x13.cisco.com> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> <8ED5B0B0F5B4854A912480C1521F973A11B2B080@xmb-rcd-x13.cisco.com> Date: Mon, 17 Feb 2014 22:45:34 +0100 X-Google-Sender-Auth: Wl401_yuQbB3IfpdF6nLceTHBrI Message-ID: From: Robert Raszuk To: "Saikat Ray (sairay)" Content-Type: multipart/alternative; boundary=001a11336f444aec6504f2a113c1 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/dM2bs0ZlDCJxRf1KMg4daUvmGto Cc: "mtexier@arbor.net" , "idr@ietf.org" , Jeff Haas , "David Smith \(djsmith\)" , "ju1738@att.com" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 21:45:42 -0000 --001a11336f444aec6504f2a113c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Saikat, Flowspec RFC5575 is not using next hop for it's actions. In fact BGP NEXT_HOP is optional. A given flow may be associated with a set of attributes, depending on the particular application; such attributes may or may not include reachability information (i.e., NEXT_HOP) Instead we use the RT match to determine which local VRF is used for redirect or mirror. Stephane's proposal is wise IMO as we could list different VRFs one for each required action. The forwarding or encapsulation itself is defined in those redirect/mirror VRFs. Redirect: The redirect extended community allows the traffic to be redirected to a VRF routing instance that lists the specified route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This extended community uses the same encoding as the Route Target extended community [RFC4360 ]. Best, R. On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay) wro= te: > A given update (a BGP path) has only one NEXTHOP (the NEXTHOP determines > where to redirect or mirror the packets). > > > > *From:* Idr [mailto:idr-bounces@ietf.org] *On Behalf Of * > stephane.litkowski@orange.com > *Sent:* Monday, February 17, 2014 1:19 AM > *To:* Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra > *Cc:* mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith > (djsmith); Jeff Haas > > *Subject:* Re: [Idr] Flowspec, coexistance of redirect and mirror actions > > > > Hi, > > > > In order to have both actions applied, why not setting twice time the > extcommunity in the BGP update ? (one with C=3D0 and one with C=3D1). > > Does this cause any issue ? > > > > Applying multiple actions by setting multiple extcts seems to be > authorized, so why not using the same thing here by setting twice time th= e > same extct with different C flag. Otherwise need to split it in two > different extcts. > > > > Thoughts ? > > > > > > Best Regards, > > > > Stephane > > > > > > *De :* Idr [mailto:idr-bounces@ietf.org ] *De la > part de* Bertrand Duvivier (bduvivie) > *Envoy=E9 :* mardi 11 f=E9vrier 2014 21:39 > *=C0 :* Robert Raszuk; Pradosh Mohapatra > *Cc :* mtexier@arbor.net; idr@ietf.org; ju1738@att.com; Jeff Haas; David > Smith (djsmith) > *Objet :* Re: [Idr] Flowspec, coexistance of redirect and mirror actions > > > > Hi, > > > > *I see 2 cases: * > > > > *Signaling primary/backup actions* > > > > We could control path priority using LP or MED. > > Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ... > > > > Of N path RR could select best 2 or 3 or all best path based on preferre= d > LP (or MED) > > BGP Client could select first action, if not possible due to NH not > available in RIB, then act on second ... etc... > > > > *Signaling multiple parallel actions.* > > > > I don't have answer for this one > > > > Bertrand > > > > > > *From:* idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] > *On Behalf Of *Robert Raszuk > *Sent:* mercredi 28 ao=FBt 2013 16:52 > *To:* Pradosh Mohapatra > *Cc:* mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); > ju1738@att.com > *Subject:* Re: [Idr] Flowspec, coexistance of redirect and mirror actions > > > > Hi Pradosh, > > > > 5575 still requires you to run BGP best path selection even if you have > multiple paths. This is both for the onward advertisement as well as for > the local installation. > > > > You are proposing to install more then "best" path locally which may > actually require substantial changes to the BGP operation. > > > > How do you control which paths are to be installed let's say which 2 out > of N ? The multipath checks are not really helpful here. > > > > It's an interesting question if we in general agree to install multiple > paths in flowspec SAFI for the exact same NLRI ? > > > > Regards, > > R. > > > > > > > > > > > > > > > > On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra > wrote: > > Hi Kaliraj, > > > > Suggest you use add-path: send two paths for the flow, one with next-hop = X > > and redirect action, the other with next-hop Y and mirror action. > > > > - Pradosh > > > ------------------------------ > > *From:* Kaliraj Vairavakkalai > *To:* "Simpson, Adam (Adam)" ; " > ju1738@att.com" ; "pmohapat@cisco.com" ; > "djsmith@cisco.com" ; "Henderickx, Wim (Wim)" < > wim.henderickx@alcatel-lucent.com>; "mtexier@arbor.net" > > *Cc:* Jeff Haas ; "idr@ietf.org" > *Sent:* Tuesday, August 27, 2013 10:55 AM > *Subject:* Re: [Idr] Flowspec, coexistance of redirect and mirror actions > > > Yes Adam, the original flow with destination A is steered/moved to new > destination B (e.g. scrubber device) while simultaneously copy of this fl= ow > sent to a new destination C (e.g. for LI) > > The devices doing the scrubbing and LI may be different (based on devices= ' > capability, load-balancing requirement etc), was the thought behind my > question. > > Thanks, > Kaliraj > > -----Original Message----- > > From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] > > Sent: Tuesday, August 27, 2013 10:19 AM > > To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com; > > djsmith@cisco.com; Henderickx, Wim (Wim); mtexier@arbor.net > > Cc: Jeff Haas; idr@ietf.org > > Subject: Re: Flowspec, coexistance of redirect and mirror actions > > > > Hi Kaliraj, > > > > You are correct; these actions are mutually exclusive according to the > current > > encoding. What does it mean for you to have a flow both moved > > (redirected) and copied (mirrored)? Do you mean the original flow with > > destination A is steered/moved to new destination B while at the same > time a > > copy of this flow is sent to a new destination C? I personally have not > seen a > > requirement for this type of compound action but I will leave the other > > authors to comment as well. > > > > -Adam > > > > > > On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" > wrote: > > > > >Hi authors, > > > > > >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > > > > > >If it is desired to perform both "redirect-action" to a nexthop X, and > > >"mirror-action" to a different nexthop Y simultaneously for the same > > >flow, how is it achieved? > > > > > >It appears the signaling for such a scenario may not be handled by the > > >mechanisms specified in this draft, unless I am missing something. > > >Could you pls clarify. > > > > > >Thanks > > >Kaliraj > > > > > > > > > > _______________________________________________ > 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 > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > --001a11336f444aec6504f2a113c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Saikat,

Flowspec RFC5575 is not using next hop for it= 's actions. In fact BGP NEXT_HOP is optional. 

   A given flow may be ass=
ociated with a set of attributes, depending on
   the particular application; such attributes may or may not include
   reachability information (i.e., NEXT_HOP)

= 
Instead we use the RT match to dete=
rmine which local VRF is used for redirect or mirror. Stephane's propos=
al is wise IMO as we could list different VRFs one for each required action=
. The forwarding or encapsulation itself is defined in those redirect/mirro=
r VRFs.





      Redirect:  The redirect extended community allows the tr=
affic to be
      redirected to a VRF routing instance that lists the specified
      route-target in its import policy.  If several local instances
      match this criteria, the choice between them is a local matter
      (for example, the instance with the lowest Route Distinguisher
      value can be elected).  This extended community uses the same
      encoding as the Route Target extended community [RFC4360].

Best,
R.





On Mon, Feb 17, 2014 at 10:33 PM, Saikat= Ray (sairay) <sairay@cisco.com> wrote:

A given update (a BGP path) = has only one NEXTHOP (the NEXTHOP determines where to redirect or mirror th= e packets).

 <= /p>

From: Idr [mai= lto:idr-bounces@i= etf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Monday, February 17, 2014 1:19 AM
To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra Cc: mtexier@a= rbor.net; idr@ietf.or= g; ju1738@att.com; David Smith (djsmith); Jeff Haas


Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons

 

Hi,=

 =

In order to have both act= ions applied, why not setting twice time the extcommunity in the BGP update= ? (one with C=3D0 and one with C=3D1).

Does this cause any issue= ?

 

Applying multiple actions= by setting multiple extcts seems to be authorized, so why not using the sa= me thing here by setting twice time the same extct with different C flag. Otherwise need to split it in two different extcts.

 

Thoughts ?<= /span>

 

 

Best Regards,

 

Stephane

 

 

De : Idr = [mailto:idr-bounc= es@ietf.org] De la part de Bertrand Duvivier (bduvivie)
Envoy=E9 : mardi 11 f=E9vrier 2014 21:39
=C0 : Robert Raszuk; Pradosh Mohapatra
Cc : mte= xier@arbor.net; idr@ietf.org; ju173= 8@att.com; Jeff Haas; David Smith (djsmith)
Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror = actions

 

Hi,

 

I see 2 cases:

 

Signaling primary/back= up actions

 

We could control path pri= ority using LP or MED.

Assuming NLRI x PATH 1 AC= TION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, …

 

Of N path RR could select= best 2 or 3 or all best path  based on preferred LP (or MED)

BGP Client could select f= irst action, if not possible due to NH not available in RIB, then act on se= cond … etc…

 

Signaling multiple par= allel actions.

 

I don’t have answer= for this one

 

Bertrand

 

 

From: idr-bounces@ietf.= org [mailto:i= dr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: mercredi 28 ao=FBt 2013 16:52
To: Pradosh Mohapatra
Cc: mtexier@a= rbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); ju1738@att.com
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons

 

= Hi Pradosh,

=  

= 5575 still requires you to run BGP best path selection even if you have mul= tiple paths. This is both for the onward advertisement as well as for the l= ocal installation. 

=  

= You are proposing to install more then "best" path locally which = may actually require substantial changes to the BGP operation. =

=  

= How do you control which paths are to be installed let's say which 2 ou= t of N ? The multipath checks are not really helpful here. <= /u>

=  

= It's an interesting question if we in general agree to install multiple= paths in flowspec SAFI for the exact same NLRI ? 

=  

= Regards,

= R.

=  

=  

=  

=  

=  

=  

 <= /p>

On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra = <mpradosh@yahoo.= com> wrote:

Hi Kaliraj,

 

Suggest you use add-path: send two paths for the flo= w, one with next-hop X 

and redirect action, the other with next-hop Y and m= irror action.

 

- Pradosh

 

From: Kaliraj Vairavakkalai <kaliraj@juniper.net>
To: "Simpson, Adam (Adam)" <adam.simpson@alcatel-lucent.com>; "ju1738@at= t.com" <ju1= 738@att.com>; "pmohapat@cis= co.com" <pmohapat@cisco.com>; "djsmith@cisco.com" <djsmith@cisco.com>; "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>= ;; "mtexier@arb= or.net" <mtexier@arbor.net>
Cc: Jeff Haas <jhaas@juniper.net>; "idr@ietf.org" <idr@ietf.org>
Sent: Tuesday, August 27, 2013 10:55 AM
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons


Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI)

The devices doing the scrubbing and LI may be different (based on devices&#= 39; capability, load-balancing requirement etc), was the thought behind my = question.

Thanks,
Kaliraj
> -----Original Message-----
> From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com]
> Sent: Tuesday, August 27, 2013 10:19 AM
> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com<= /a>;
> djsmith@cisco.c= om; Henderickx, Wim (Wim); mtexier@arbor.net
> Cc: Jeff Haas; idr@i= etf.org
> Subject: Re: Flowspec, coexistance of redirect and mirror actions
>
> Hi Kaliraj,
>
> You are correct; these actions are mutually exclusive according to the= current
> encoding. What does it mean for you to have a flow both moved
> (redirected) and copied (mirrored)? Do you mean the original flow with=
> destination A is steered/moved to new destination B while at the same = time a
> copy of this flow is sent to a new destination C? I personally have no= t seen a
> requirement for this type of compound action but I will leave the othe= r
> authors to comment as well.
>
> -Adam
>
>
> On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" <kaliraj@juniper.net&g= t; wrote:
>
> >Hi authors,
> >
> >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02
> >
> >If it is desired to perform both "redirect-action" to a = nexthop X, and
> >"mirror-action" to a different nexthop Y simultaneously = for the same
> >flow, how is it achieved?
> >
> >It appears the signaling for such a scenario may not be handled by= the
> >mechanisms specified in this draft, unless I am missing something.=
> >Could you pls clarify.
> >
> >Thanks
> >Kaliraj
> >
>
>


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


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

 

____________________________________________________=
_____________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;=

they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.=

Thank you.

--001a11336f444aec6504f2a113c1-- From nobody Mon Feb 17 14:02:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EEE1A050A for ; Mon, 17 Feb 2014 14:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttu5VDLZFZ4g for ; Mon, 17 Feb 2014 14:02:50 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E07C51A041D for ; Mon, 17 Feb 2014 14:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44803; q=dns/txt; s=iport; t=1392674567; x=1393884167; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e4+PL8Ox97rpci8iCmBTo1RuTpV5xCZqCZknL0LzTkY=; b=lJR6x5AVyjHb1uvTG0zT+BZU1ibUVrOPdTWYL5hw7lcXnFnNYWpEqfyZ UOxMPgllQKEkZm9BZtuBv6KZEXg/8aARxFlyG7dyOCOhti/WDtEjB7Bvp 2JMtoXs+drMwZJUmKmJqWPRz+rc1PooR4W0sIuskJrvas1VBBQYvvLP+v s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYGAMOGAlOtJV2Z/2dsb2JhbABZgkREOFWqB4okiFOBIxYBdIN9AQEBBAEBASpBCwwEAgEIEQQBAQEKFgEGByEGCxMBCQgCBA4FCAyHXAMRDbl+DYgOF4x/gSgJEQEfHwgFAQQGAQaDHYETAQOJC4sogXgGgxWLKoU6gyuBcTk X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208,217";a="301629241" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 17 Feb 2014 22:02:45 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1HM2j3e023297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 22:02:45 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.119]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 16:02:45 -0600 From: "Saikat Ray (sairay)" To: Robert Raszuk Thread-Topic: [Idr] Flowspec, coexistance of redirect and mirror actions Thread-Index: AQHOo/436d64LadntUuqPTw52t2IbJqxhuZggAixvVCAAM664IAAaGcA//+fjyA= Date: Mon, 17 Feb 2014 22:02:45 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A11B2B12C@xmb-rcd-x13.cisco.com> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> <8ED5B0B0F5B4854A912480C1521F973A11B2B080@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.165.99] Content-Type: multipart/alternative; boundary="_000_8ED5B0B0F5B4854A912480C1521F973A11B2B12Cxmbrcdx13ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/15vRgyt0ZRn0qNzdCRRHBhIDdsw Cc: "mtexier@arbor.net" , "idr@ietf.org" , Jeff Haas , "David Smith \(djsmith\)" , "ju1738@att.com" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 22:02:55 -0000 --_000_8ED5B0B0F5B4854A912480C1521F973A11B2B12Cxmbrcdx13ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was referring to draft-simpson-idr-flowspec-redirect. "The filter entry matches the IP packets described in the NLRI field and redirects them (C=3D0) or copies them (C=3D1) towards the IPv4 or IPv6 address specified in the 'Network Address of Next- Hop' field of the associated MP_REACH_NLRI." I assumed this thread is for draft-simpson-idr-flowspec-redirect since that= is what the first email in the thread refers to. From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Monday, February 17, 2014 1:46 PM To: Saikat Ray (sairay) Cc: stephane.litkowski@orange.com; Bertrand Duvivier (bduvivie); Pradosh Mo= hapatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith (djsm= ith); Jeff Haas Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Saikat, Flowspec RFC5575 is not using next hop for it's actions. In fact BGP NEXT_H= OP is optional. A given flow may be associated with a set of attributes, depending on the particular application; such attributes may or may not include reachability information (i.e., NEXT_HOP) Instead we use the RT match to determine which local VRF is used for redire= ct or mirror. Stephane's proposal is wise IMO as we could list different VR= Fs one for each required action. The forwarding or encapsulation itself is = defined in those redirect/mirror VRFs. Redirect: The redirect extended community allows the traffic to be redirected to a VRF routing instance that lists the specified route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This extended community uses the same encoding as the Route Target extended community [RFC4360]. Best, R. On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay) > wrote: A given update (a BGP path) has only one NEXTHOP (the NEXTHOP determines wh= ere to redirect or mirror the packets). From: Idr [mailto:idr-bounces@ietf.org] On Beh= alf Of stephane.litkowski@orange.com Sent: Monday, February 17, 2014 1:19 AM To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra Cc: mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith (djsmith); Jeff= Haas Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi, In order to have both actions applied, why not setting twice time the extco= mmunity in the BGP update ? (one with C=3D0 and one with C=3D1). Does this cause any issue ? Applying multiple actions by setting multiple extcts seems to be authorized= , so why not using the same thing here by setting twice time the same extct= with different C flag. Otherwise need to split it in two different extcts. Thoughts ? Best Regards, Stephane De : Idr [mailto:idr-bounces@ietf.org] De la part de Bertrand Duvivier (bdu= vivie) Envoy=E9 : mardi 11 f=E9vrier 2014 21:39 =C0 : Robert Raszuk; Pradosh Mohapatra Cc : mtexier@arbor.net; idr@ietf.org; ju1738@att.com; Jeff Haas; David Smith (dj= smith) Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi, I see 2 cases: Signaling primary/backup actions We could control path priority using LP or MED. Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ... Of N path RR could select best 2 or 3 or all best path based on preferred = LP (or MED) BGP Client could select first action, if not possible due to NH not availab= le in RIB, then act on second ... etc... Signaling multiple parallel actions. I don't have answer for this one Bertrand From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Robert Raszuk Sent: mercredi 28 ao=FBt 2013 16:52 To: Pradosh Mohapatra Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); ju1738@att.com Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi Pradosh, 5575 still requires you to run BGP best path selection even if you have mul= tiple paths. This is both for the onward advertisement as well as for the l= ocal installation. You are proposing to install more then "best" path locally which may actual= ly require substantial changes to the BGP operation. How do you control which paths are to be installed let's say which 2 out of= N ? The multipath checks are not really helpful here. It's an interesting question if we in general agree to install multiple pat= hs in flowspec SAFI for the exact same NLRI ? Regards, R. On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra > wrote: Hi Kaliraj, Suggest you use add-path: send two paths for the flow, one with next-hop X and redirect action, the other with next-hop Y and mirror action. - Pradosh ________________________________ From: Kaliraj Vairavakkalai > To: "Simpson, Adam (Adam)" >; "ju1738@att.com" >; "pmohapat@cisco.com" >; "djsmith@cisco.com" >; "H= enderickx, Wim (Wim)" >; "mtexier@arbor.net" > Cc: Jeff Haas >; "idr@ietf.org<= mailto:idr@ietf.org>" > Sent: Tuesday, August 27, 2013 10:55 AM Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI) The devices doing the scrubbing and LI may be different (based on devices' = capability, load-balancing requirement etc), was the thought behind my ques= tion. Thanks, Kaliraj > -----Original Message----- > From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] > Sent: Tuesday, August 27, 2013 10:19 AM > To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapa= t@cisco.com; > djsmith@cisco.com; Henderickx, Wim (Wim); mtexi= er@arbor.net > Cc: Jeff Haas; idr@ietf.org > Subject: Re: Flowspec, coexistance of redirect and mirror actions > > Hi Kaliraj, > > You are correct; these actions are mutually exclusive according to the cu= rrent > encoding. What does it mean for you to have a flow both moved > (redirected) and copied (mirrored)? Do you mean the original flow with > destination A is steered/moved to new destination B while at the same tim= e a > copy of this flow is sent to a new destination C? I personally have not s= een a > requirement for this type of compound action but I will leave the other > authors to comment as well. > > -Adam > > > On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" > wrote: > > >Hi authors, > > > >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > > > >If it is desired to perform both "redirect-action" to a nexthop X, and > >"mirror-action" to a different nexthop Y simultaneously for the same > >flow, how is it achieved? > > > >It appears the signaling for such a scenario may not be handled by the > >mechanisms specified in this draft, unless I am missing something. > >Could you pls clarify. > > > >Thanks > >Kaliraj > > > > _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8ED5B0B0F5B4854A912480C1521F973A11B2B12Cxmbrcdx13ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I was referring to draft-sim= pson-idr-flowspec-redirect.

 

“The filter entry matc= hes the IP packets described in

   the NLRI field = and redirects them (C=3D0) or copies them (C=3D1) towards=

   the IPv4 or IPv= 6 address specified in the 'Network Address of Next-

   Hop' field of t= he associated MP_REACH_NLRI.”

 

I assumed this thread is for= draft-simpson-idr-flowspec-redirect since that is what the first email in = the thread refers to.

 

From: rraszuk@= gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Monday, February 17, 2014 1:46 PM
To: Saikat Ray (sairay)
Cc: stephane.litkowski@orange.com; Bertrand Duvivier (bduvivie); Pra= dosh Mohapatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smit= h (djsmith); Jeff Haas
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons

 

= Saikat,

=  

= Flowspec RFC5575 is not using next hop for it's actions. In fact BGP NEXT_H= OP is optional. 

=  

   A given flow=
 may be associated with a set of attributes, depending on=

   the particul=
ar application; such attributes may or may not include

   reachability=
 information (i.e., NEXT_HOP)


 <=
/pre>

 <=
/pre>

Instead we use the RT m=
atch to determine which local VRF is used for redirect or mirror. Stephane'=
s proposal is wise IMO as we could list different VRFs one for each require=
d action. The forwarding or encapsulation itself is defined in those redire=
ct/mirror VRFs.

=



 <=
/pre>

    &=
nbsp; Redirect:  The redirect extended community allows the traffic to=
 be


    &=
nbsp; redirected to a VRF routing instance that lists the specified


    &=
nbsp; route-target in its import policy.  If several local instances


     =
 match this criteria, the choice between them is a local matter


    &=
nbsp; (for example, the instance with the lowest Route Distinguisher


    &=
nbsp; value can be elected).  This extended community uses the same


    &=
nbsp; encoding as the Route Target extended community [RFC4360].


 <=
/pre>

 <=
/pre>

Best,

R.

 <=
/pre>

 <=
/pre>

 <=
/pre>

 <=
/pre>

 

On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay= ) <sairay@cisco.co= m> wrote:

A given update (a BGP path) has only one N= EXTHOP (the NEXTHOP determines where to redirect or mirror the packets).

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Monday, February 17, 2014 1:19 AM
To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra Cc: mtexier@a= rbor.net; idr@ietf.org; ju1738@att.com; David Smith (djsmith); Jeff Haas


Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons

 

Hi,

 

In order to have both actions applied, = why not setting twice time the extcommunity in the BGP update ? (one with C=3D0 and one with C=3D1).

Does this cause any issue ?=

 

Applying multiple actions by setting mu= ltiple extcts seems to be authorized, so why not using the same thing here by setting twice time the same extct with different C flag= . Otherwise need to split it in two different extcts.

 

Thoughts ?

 

 

Best Regards,

 

Stephane

 

 

 

Hi,

 

I see 2 cases:

 

Signaling primary/backup actions

 

We could control path priority using LP= or MED.

Assuming NLRI x PATH 1 ACTION 1 LP 1, N= LRI x PATH 2 ACTION 2 LP2, …

 

Of N path RR could select best 2 or 3 o= r all best path  based on preferred LP (or MED)

BGP Client could select first action, i= f not possible due to NH not available in RIB, then act on second … etc…

 

Signaling multiple parallel actions.=

 

I don’t have answer for this one<= /span>

 

Bertrand

 

 

From: idr-bounces@ietf.= org [mailto:i= dr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: mercredi 28 ao=FBt 2013 16:52
To: Pradosh Mohapatra
Cc: mtexier@a= rbor.net; idr@ietf.org; Jeff Ha= as; David Smith (djsmith); ju1738@att.com
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons

 

Hi Pradosh,

 <= o:p>

5575 still req= uires you to run BGP best path selection even if you have multiple paths. T= his is both for the onward advertisement as well as for the local installation. 

 <= o:p>

You are propos= ing to install more then "best" path locally which may actually r= equire substantial changes to the BGP operation. 

 <= o:p>

How do you con= trol which paths are to be installed let's say which 2 out of N ? The multi= path checks are not really helpful here. 

 <= o:p>

It's an intere= sting question if we in general agree to install multiple paths in flowspec= SAFI for the exact same NLRI ? 

 <= o:p>

Regards,

R.=

 <= o:p>

 <= o:p>

 <= o:p>

 <= o:p>

 <= o:p>

 <= o:p>

 

On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra <mpradosh@yahoo.com> wr= ote:

Hi Kaliraj,

 

Suggest you use add-path: send two paths for the flow, one with ne= xt-hop X 

and redirect action, the other with next-hop Y and mirror action.<= o:p>

 

- Pradosh

 

From: Kaliraj Vairavakkalai <kaliraj@juniper.net>
To: "Simpson, Adam (Adam)" <adam.simpson@alcatel-lucent.com>; "ju1738@at= t.com" <ju1= 738@att.com>; "pmohapat@cis= co.com" <pmohapat@cisco.com>; "djsmith@cisco.com" <djsmith@cisco.com>; "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>= ;; "mtexier@arb= or.net" <mtexier@arbor.net>
Cc: Jeff Haas <jhaas@juniper.net>; "idr@ietf.org" <idr@ietf.org>
Sent: Tuesday, August 27, 2013 10:55 AM
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror acti= ons


Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI)

The devices doing the scrubbing and LI may be different (based on devices' = capability, load-balancing requirement etc), was the thought behind my ques= tion.

Thanks,
Kaliraj
> -----Original Message-----
> From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com]
> Sent: Tuesday, August 27, 2013 10:19 AM
> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com<= /a>;
> djsmith@cisco.c= om; Henderickx, Wim (Wim); mtexier@arbor.net
> Cc: Jeff Haas; idr@i= etf.org
> Subject: Re: Flowspec, coexistance of redirect and mirror actions
>
> Hi Kaliraj,
>
> You are correct; these actions are mutually exclusive according to the= current
> encoding. What does it mean for you to have a flow both moved
> (redirected) and copied (mirrored)? Do you mean the original flow with=
> destination A is steered/moved to new destination B while at the same = time a
> copy of this flow is sent to a new destination C? I personally have no= t seen a
> requirement for this type of compound action but I will leave the othe= r
> authors to comment as well.
>
> -Adam
>
>
> On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" <kaliraj@juniper.net&g= t; wrote:
>
> >Hi authors,
> >
> >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02
> >
> >If it is desired to perform both "redirect-action" to a = nexthop X, and
> >"mirror-action" to a different nexthop Y simultaneously = for the same
> >flow, how is it achieved?
> >
> >It appears the signaling for such a scenario may not be handled by= the
> >mechanisms specified in this draft, unless I am missing something.=
> >Could you pls clarify.
> >
> >Thanks
> >Kaliraj
> >
>
>


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


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

 

____________________________________________________=
_____________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.

 

--_000_8ED5B0B0F5B4854A912480C1521F973A11B2B12Cxmbrcdx13ciscoc_-- From nobody Mon Feb 17 15:02:22 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2718F1A0411 for ; Mon, 17 Feb 2014 15:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN8LdL4SGvNy for ; Mon, 17 Feb 2014 15:02:17 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 489F51A02AE for ; Mon, 17 Feb 2014 15:02:17 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id BC2C1C5B7; Mon, 17 Feb 2014 18:02:14 -0500 (EST) Date: Mon, 17 Feb 2014 18:02:14 -0500 From: Jeffrey Haas To: "Saikat Ray (sairay)" Message-ID: <20140217230214.GA12348@pfrc> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> <8ED5B0B0F5B4854A912480C1521F973A11B2B080@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A11B2B12C@xmb-rcd-x13.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A11B2B12C@xmb-rcd-x13.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/VBU8olJbhKRCuljZqWFqHmLa1_Q Cc: "mtexier@arbor.net" , "idr@ietf.org" , Robert Raszuk , Jeff Haas , "David Smith \(djsmith\)" , "ju1738@att.com" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:02:19 -0000 On Mon, Feb 17, 2014 at 10:02:45PM +0000, Saikat Ray (sairay) wrote: > I was referring to draft-simpson-idr-flowspec-redirect. > > "The filter entry matches the IP packets described in > the NLRI field and redirects them (C=0) or copies them (C=1) towards > the IPv4 or IPv6 address specified in the 'Network Address of Next- > Hop' field of the associated MP_REACH_NLRI." > > I assumed this thread is for draft-simpson-idr-flowspec-redirect since that is what the first email in the thread refers to. There is a side discussion in progress toward both updating the marking mechanism and also clarifying the case where more than one copy of the community is present. Based on the pace of the discussion, I suspect all involved are having busy work months. :-) -- Jeff From nobody Mon Feb 17 15:20:31 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB261A055C for ; Mon, 17 Feb 2014 15:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uisYl9EauqZc for ; Mon, 17 Feb 2014 15:20:21 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 688461A0590 for ; Mon, 17 Feb 2014 15:20:13 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 17 Feb 2014 17:20:10 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f169.google.com [209.85.213.169] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f169.google.com with SMTP id uq10so6142494igb.0 for ; Mon, 17 Feb 2014 15:20:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xaHYmIquxH3u08ijAsPWjaTey4npX8ucO+pGHaL3k1Q=; b=VnwbBggeD6UcVfqCxZVVm0reDbwSLe1BuqqIqctlr1zd83fkLWD2eDECf9lxTYtikB 4ZLvyVrB9XOywhF1nhsdByV9xO6/bUqqY7Nx5rw228vAcOfHuriLlk8pUbLhxdLLsrqX H9oOB3BA2DUrQqPVNj9vjzowm31TIl9uC0V1Qe4w2s5p/YKzoVZsotBEaQld/eW4RhXZ FstJWje1SIL7hk4NojWi+isgjPHGsWUlhmXy2eQIZptLevbzjjcdHJsUOlG09zRsoxLE 8BIizql5bEwGiPK55dbkPjgi7IFhn17ipLa/vsHifWH8mALHpC6CDTND1f5J7rP7a5XQ RWEA== X-Gm-Message-State: ALoCoQnSw9jAwCiXz36cSRJ0+Hf5a/fTiyTQoRduwwnNLSZJarQCXFAtYjU1ZVeWPPiwKy1dBrPg1RHO+OFUvV4up+WeCRG7ilnyTDaPKIy09cqAjuqhg1P1GliIwMW7+ykyj6SVcAhE X-Received: by 10.50.122.8 with SMTP id lo8mr19178024igb.31.1392679210071; Mon, 17 Feb 2014 15:20:10 -0800 (PST) X-Received: by 10.50.122.8 with SMTP id lo8mr19178007igb.31.1392679209881; Mon, 17 Feb 2014 15:20:09 -0800 (PST) Received: from x-160-94-249-105.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:fd29:5012:9352:d3d6]) by mx.google.com with ESMTPSA id kb5sm35345728igb.1.2014.02.17.15.20.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Feb 2014 15:20:08 -0800 (PST) Message-ID: <53029926.5030002@umn.edu> Date: Mon, 17 Feb 2014 17:20:06 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: joel jaeggli , Shane Amante References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> <530270E8.5090603@bogus.com> In-Reply-To: <530270E8.5090603@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/idr/menGlrKQIjt4QBoddUbFeaRS2Nc Cc: V6 Ops List , idr wg Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:20:22 -0000 On 2/17/14, 14:28 , joel jaeggli wrote: > On 2/15/14, 11:25 AM, David Farmer wrote: > >> As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205. >> Then you can use an IPv6 loopback address of 2001:db8:1::c000:205, or >> you could even used mixed notation 2001:db8:1::192.0.2.5. > > You could, but you shouldn't whether it's merely shorthand or not > because ipv6 mapped ipv4 addresses and accompanying notation are are > sort of ugly representation that will be throwing junior network > operators under the bus for years to come. > > http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00 I'd prefer to recommend that implementations include a hex representation of the ROUTER_ID, either in addition to or instead of the dotted quad decimal representation. I need to study it more closely, but I think what I'm suggesting is compatible with the recommendation in RFC5952 Section 5. However, I take your point, even if compatible with RFC5952 Section 5, its best to avoid the problem if possible. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Mon Feb 17 18:32:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444D81A02F3; Mon, 17 Feb 2014 18:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.376 X-Spam-Level: X-Spam-Status: No, score=0.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAJqONNTp75F; Mon, 17 Feb 2014 18:32:08 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 090EC1A0164; Mon, 17 Feb 2014 18:32:07 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302c599b7f-f2b7f; Tue, 18 Feb 2014 10:29:46 +0800 (CST) X-RM-TRANSID: 2ee15302c599b7f-f2b7f Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35302c599baf-db74a; Tue, 18 Feb 2014 10:29:46 +0800 (CST) X-RM-TRANSID: 2ee35302c599baf-db74a Date: Tue, 18 Feb 2014 10:31:57 +0800 From: "lizhenqiang@chinamobile.com" To: "Randy Bush" , fanpeng References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , <006801cf2b34$22837cd0$678a7670$@chinamobile.com>, , <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com>, , <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com>, , <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <201402181031568885348@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart050641472535_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ZmqgdX5I9gRb5gHGzgI3ePevBXI Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 02:32:11 -0000 This is a multi-part message in MIME format. ------=_001_NextPart050641472535_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 CgoKCgoKSGkgUmFuZHksCkRvIHlvdSBoYXZlIHN1Y2ggdG9vbHMgdG8gY29uZmlnIHlvdXIgbmV0 d29yaz8gT3IgZG8geW91IGtub3cgdGhlIHZlbmRvciB0aGF0IHByb3ZpZGUgc3VjaCB0b29scz9J bmRlZWQsIHN1Y2jCoHByb2dyYW1tYXRpYyBnZW5lcmF0aW9uIHRvb2xzIGFyZSBnb29kIGZvciBu ZXR3b3JrIHBsYW4uIEJ1dCB0aGUgbG9naWMgaW4gdGhlIHRvb2xzIGlzIGNvbXBsZWNhdGVkIGVz cGVjaWFsbHkgZm9yIGEgdmVyeSBsYXJnZSBuZXR3b3JrIHdpdGjCoGhpZXJhcmNoaWNhbCBvcGVy YXRpb24gYXMgUGVuZyBGYW4gbWVudGlvbmVkLgoKWmhlbnFpYW5nIExpCgrCoEZyb206wqBSYW5k eSBCdXNoRGF0ZTrCoDIwMTQtMDItMTfCoDIyOjUwVG86wqBGYW4sIFBlbmdDQzrCoCdpZHIgd2cn OyAnVjYgT3BzIExpc3QnOyAnUm9iZXJ0IFJhc3p1aydTdWJqZWN0OsKgUmU6IFtJZHJdIFt2Nm9w c10gQkdQIElkZW50aWZpZXI+IFdvdWxkIHlvdSBwbGVhc2UgZ2l2ZSBtZSBhbiBleGFtcGxlIGFi b3V0IGhvdyBtb2Rlcm4gbGFyZ2UgSVNQcyBtYW5hZ2UgdGhlaXIKPiBuZXR3b3Jrcz8KwqAKcHJv Z3JhbW1hdGljIGdlbmVyYXRpb24gb2YgY29uZmlndXJhdGlvbnMgZnJvbSBkYXRhYmFzZXMuCsKg CnJhbmR5CsKgCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CklkciBtYWlsaW5nIGxpc3QKSWRyQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWRyCsKgCgo= ------=_001_NextPart050641472535_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
Hi Randy,

Do you have such tools to config you= r network? Or do you know the vendor that provide such tools?
In= deed, such programmatic generation tools are good for network pl= an. But the logic in the tools is complecated especially for a very large = network with hierarchical operation as Peng Fan mentioned.=0A

Zhenqiang Li

=0A
 
From: Randy Bush
Date: 2014-02-17 22:50
Subject: Re: = [Idr] [v6ops] BGP Identifier
> Would you ple= ase give me an example about how modern large ISPs manage their
=0A> networks?
=0A
 
=0A
programmatic generation= of configurations from databases.
=0A
 
=0A
randy<= /div>=0A
 
=0A
_________________________________________= ______
=0A
Idr mailing list
=0A
Idr@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/idr
=0A
 
=0A
=0A ------=_001_NextPart050641472535_=------ From nobody Mon Feb 17 18:33:18 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA83E1A030B; Mon, 17 Feb 2014 18:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R_Hq1LiDFZe; Mon, 17 Feb 2014 18:33:11 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id DB6201A0317; Mon, 17 Feb 2014 18:33:09 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302c5e3bd4-f2bd4; Tue, 18 Feb 2014 10:30:59 +0800 (CST) X-RM-TRANSID: 2ee15302c5e3bd4-f2bd4 Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee25302c5e2c63-f48f9; Tue, 18 Feb 2014 10:30:59 +0800 (CST) X-RM-TRANSID: 2ee25302c5e2c63-f48f9 Date: Tue, 18 Feb 2014 10:33:09 +0800 From: "lizhenqiang@chinamobile.com" To: =?ISO-8859-1?B?VVRUQVJPLCBKQU1FUw==?= , "Randy Bush" , fanpeng References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , <006801cf2b34$22837cd0$678a7670$@chinamobile.com>, , <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com>, , <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com>, , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <201402181033092475009@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart002576354625_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/3LwR86Ke26vE8Z_D1jN1DnWy50U Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 02:33:14 -0000 This is a multi-part message in MIME format. ------=_001_NextPart002576354625_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 CgoKCgoKWWVzIHdlIGRvIGlmIHdlIGNvdWxkLgoKWmhlbnFpYW5nIExpCgqgRnJvbTqgVVRUQVJP LCBKQU1FU0RhdGU6oDIwMTQtMDItMTegMjM6NTJUbzqgUmFuZHkgQnVzaDsgRmFuLCBQZW5nQ0M6 oCdpZHIgd2cnOyAnVjYgT3BzIExpc3QnOyAnUm9iZXJ0IFJhc3p1aydTdWJqZWN0OqBSZTogW0lk cl0gW3Y2b3BzXSBCR1AgSWRlbnRpZmllcldlIGVuZGVhdm9yIHRvIGF1dG9tYXRlIGFzIG11Y2gg YXMgcG9zc2libGUgYXMgbWFudWFsL2h1bWFuIG1hbmlwdWxhdGlvbiB1c3VhbGx5IHJlc3VsdHMg aW4gYSBiaWcgZXJyb3IgYXQgc29tZSBwb2ludC4uCqAKSmltIFV0dGFybwqgCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgUmFuZHkgQnVzaApTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE3LCAyMDE0IDU6 MjYgQU0KVG86IEZhbiwgUGVuZwpDYzogJ2lkciB3Zyc7ICdWNiBPcHMgTGlzdCc7ICdSb2JlcnQg UmFzenVrJwpTdWJqZWN0OiBSZTogW0lkcl0gW3Y2b3BzXSBCR1AgSWRlbnRpZmllcgqgCj4gWWVz IHRoYXQgaXMgYSBwb3NzaWJsZSBzb2x1dGlvbiBmb3IgdHJvdWJsZXNob290aW5nLCBvbmNlIHRo ZSByb3V0ZXJfaWQgaGFzCj4gYmVlbiBkZXRlcm1pbmVkLiBCdXQgaG93IGRvIHlvdSBkZXRlcm1p bmUgYXQgZmlyc3QgdGhlIHZhbHVlIG9mIGEuYi5jLmQgd2hlbgo+IHRoZXJlIGlzIG5vIGlwdjQg YWRkcmVzcyB0byBiZSByZWZlcnJlZCB0bywgZXNwZWNpYWxseSBpbiBhbiBhdXRvbWF0aWMKPiBt YW5uZXI/IEJlZm9yZWhhbmQgcGxhbm5pbmcgd29yayBmb3IgdGhlIGlkcyBmb3IgdGhlIGVudGly ZSBuZXR3b3JrIGlzCj4gc29tZXRoaW5nIEkgYW0gY29uY2VybmVkIHdpdGggOikKoAphbGwgeW91 ciBjb21tZW50cyBhcmUgc3ltcHRvbXMgb2YgdGhlIGluc2FuaXR5IG9mIHRyeWluZyB0byBjb25m aWd1cmUgYQpsYXJnZSBuZXR3b3JrIG1hbnVhbGx5LqAgdGhpcyB3ZW50IG91dCBvZiBmYXNoaW9u IGluIHRoZSBsYXN0IGNlbnR1cnksCmFuZCB3ZSBkbyBub3QgdHJ5IHRvIGNvbXBlbnNhdGUgZm9y IGluc2FuaXR5IHRocm91Z2ggcHJvdG9jb2wKbW9kaWZpY2F0aW9uLgqgCnJhbmR5CqAKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSWRyIG1haWxpbmcgbGlz dApJZHJAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIK oApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpJZHIgbWFp bGluZyBsaXN0CklkckBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcgqgCgo= ------=_001_NextPart002576354625_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Yes we do if we could.=0A

Zhenqiang Li

=0A
 
=
Date: 2014-02-17 23:5= 2
Subject: Re: [Idr] [v6ops] BGP I= dentifier
We endeavor to automate as much as po= ssible as manual/human manipulation usually results in a big error at some= point..
=0A
 
=0A
Jim Uttaro
=0A
 =0A
-----Original Message-----
=0A
From: Idr [mailto:idr-= bounces@ietf.org] On Behalf Of Randy Bush
=0A
Sent: Monday, Febru= ary 17, 2014 5:26 AM
=0A
To: Fan, Peng
=0A
Cc: 'idr wg';= 'V6 Ops List'; 'Robert Raszuk'
=0A
Subject: Re: [Idr] [v6ops] BG= P Identifier
=0A
 
=0A
> Yes that is a possible = solution for troubleshooting, once the router_id has
=0A
> bee= n determined. But how do you determine at first the value of a.b.c.d when<= /div>=0A
> there is no ipv4 address to be referred to, especially i= n an automatic
=0A
> manner? Beforehand planning work for the = ids for the entire network is
=0A
> something I am concerned w= ith :)
=0A
 
=0A
all your comments are symptoms of = the insanity of trying to configure a
=0A
large network manually.=   this went out of fashion in the last century,
=0A
and we d= o not try to compensate for insanity through protocol
=0A
modific= ation.
=0A
 
=0A
randy
=0A
 
=0A=
_______________________________________________
=0A
Idr mail= ing list
=0A
Idr@ietf.org
=0A
https://www.ietf.org/mailm= an/listinfo/idr
=0A
 
=0A
_________________________= ______________________
=0A
Idr mailing list
=0A
Idr@ietf= .org
=0A
https://www.ietf.org/mailman/listinfo/idr
=0A
&= nbsp;
=0A
=0A ------=_001_NextPart002576354625_=------ From nobody Mon Feb 17 18:40:27 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047241A02E3; Mon, 17 Feb 2014 18:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvbYoOdg_F9g; Mon, 17 Feb 2014 18:40:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 766861A02DA; Mon, 17 Feb 2014 18:40:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFabY-0002qE-6a; Tue, 18 Feb 2014 02:40:16 +0000 Date: Tue, 18 Feb 2014 10:40:13 +0800 Message-ID: From: Randy Bush To: "lizhenqiang@chinamobile.com" In-Reply-To: <201402181031568885348@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/YgvTpTcNXgD4FiRI25oKQ0SvkNY Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 02:40:26 -0000 > Do you have such tools to config your network? Or do you know the > vendor that provide such tools?Indeed, such=A0programmatic generation > tools are good for network plan. But the logic in the tools is > complecated especially for a very large network with=A0hierarchical > operation as Peng Fan mentioned. there are products in the space, but the large providers i know who configure programatically developed their own. there are not enough large providers not suffering from 'not invented here' to make a reasonable customer base for serious software development. but it pays for itself, so smart folk who develop it. randy From nobody Mon Feb 17 18:45:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05601A0020; Mon, 17 Feb 2014 18:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.757 X-Spam-Level: X-Spam-Status: No, score=0.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pSzRF1Kbrl7; Mon, 17 Feb 2014 18:45:08 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A911F1A0314; Mon, 17 Feb 2014 18:45:07 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302c8b0f60-f2f60; Tue, 18 Feb 2014 10:42:56 +0800 (CST) X-RM-TRANSID: 2ee15302c8b0f60-f2f60 Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35302c8af046-dbc3d; Tue, 18 Feb 2014 10:42:56 +0800 (CST) X-RM-TRANSID: 2ee35302c8af046-dbc3d Date: Tue, 18 Feb 2014 10:45:07 +0800 From: "lizhenqiang@chinamobile.com" To: "Christopher Morrow" , "Randy Bush" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , <006801cf2b34$22837cd0$678a7670$@chinamobile.com>, , <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com>, , <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com>, , <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com>, , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <2014021810450694712020@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart726360527875_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Uy-O8ovdBcyyEjcl9kzTm6_qT5o Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 02:45:11 -0000 This is a multi-part message in MIME format. ------=_001_NextPart726360527875_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 CgoKCgoKVGhhbmsgeW91IHZlcnkgbXVjaCwgTXIuIE1vcnJvdy4KWWVzLCBpdCBpcyBhIGdvb2Qg c3RhcnQuIEkgd2lsbCBjb250YWN0IFZpamF5IGZvciBkZXRhaWwuIEhvd2V2ZXIsIEkgZG8gbm90 IHNlZSB0aGUgZnVuY3Rpb24gdGhhdCB3ZSB3YW50IGZyb20gdGhlIHNsaWRlcy4gSW4gZmFjdCwg d2UgYWxzbyB1c2Ugc29tZSB0b29scyB0byBhc3Npc3Qgb3VyIG5ldHdvcmsgcGxhbi4gSG93ZXZl ciwgdGhlIHRvb2xzIGNhbiBub3Qgc2F0aXNmeSBzdWNoIGNvbXBsZXggcmVxdWlyZW1lbnQuIElu IGHCoGhpZXJhcmNoaWNhbCBvcGVyYXRpb24gbmV0d29yaywgdGhlIHRvb2xzIHRvIGltcGxlbWVu dCB0aGUgbG9naWMgd2Ugd2FudCBpcyBub3QgYSBlYXN5IGpvYi4KWmhlbnFpYW5nIExpCgoKwqBG cm9tOsKgQ2hyaXN0b3BoZXIgTW9ycm93RGF0ZTrCoDIwMTQtMDItMTfCoDIzOjU5VG86wqBSYW5k eSBCdXNoQ0M6wqBpZHIgd2c7IFY2IE9wcyBMaXN0OyBSb2JlcnQgUmFzenVrU3ViamVjdDrCoFJl OiBbSWRyXSBbdjZvcHNdIEJHUCBJZGVudGlmaWVyaHR0cDovL3d3dy5uYW5vZy5vcmcvbWVldGlu Z3MvbmFub2c0NC9wcmVzZW50YXRpb25zL01vbmRheS9HaWxsX3Byb2dyYW1hdGljX040NC5wZGYK wqAKTWlrZSdzIHByZXNlbnRhdGlvbiAoZ2l2ZW4gYnkgdmlqYXkpIGlzIGEgZGVjZW50IHN0YXJ0 Li4uCsKgCk9uIE1vbiwgRmViIDE3LCAyMDE0IGF0IDk6NTAgQU0sIFJhbmR5IEJ1c2ggPHJhbmR5 QHBzZy5jb20+IHdyb3RlOgo+PiBXb3VsZCB5b3UgcGxlYXNlIGdpdmUgbWUgYW4gZXhhbXBsZSBh Ym91dCBob3cgbW9kZXJuIGxhcmdlIElTUHMgbWFuYWdlIHRoZWlyCj4+IG5ldHdvcmtzPwo+Cj4g cHJvZ3JhbW1hdGljIGdlbmVyYXRpb24gb2YgY29uZmlndXJhdGlvbnMgZnJvbSBkYXRhYmFzZXMu Cj4KPiByYW5keQo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiBJZHIgbWFpbGluZyBsaXN0Cj4gSWRyQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIKwqAKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KSWRyIG1haWxpbmcgbGlzdApJZHJAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIKwqAKCg== ------=_001_NextPart726360527875_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
Thank you very much, Mr. Morrow.

Yes, it is a = good start. I will contact Vijay for detail. However, I do not see the fun= ction that we want from the slides. In fact, we also use some tools to ass= ist our network plan. However, the tools can not satisfy such complex requ= irement. In a hierarchical operation network, the tools to implement the log= ic we want is not a easy job.

Zhenqiang Li
=0A

=0A 
Date: 2014-02-17 23:59
Sub= ject: Re: [Idr] [v6ops] BGP Identifier
http://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programat= ic_N44.pdf
=0A
 
=0A
Mike's presentation (given by = vijay) is a decent start...
=0A
 
=0A
On Mon, Feb 1= 7, 2014 at 9:50 AM, Randy Bush <randy@psg.com> wrote:
=0A
&= gt;> Would you please give me an example about how modern large ISPs ma= nage their
=0A
>> networks?
=0A
>
=0A
= > programmatic generation of configurations from databases.
=0A>
=0A
> randy
=0A
>
=0A
> _______= ________________________________________
=0A
> Idr mailing lis= t
=0A
> Idr@ietf.org
=0A
> https://www.ietf.org/ma= ilman/listinfo/idr
=0A
 
=0A
______________________= _________________________
=0A
Idr mailing list
=0A
Idr@i= etf.org
=0A
https://www.ietf.org/mailman/listinfo/idr
=0A 
=0A
=0A ------=_001_NextPart726360527875_=------ From nobody Mon Feb 17 18:51:46 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5687A1A02DA; Mon, 17 Feb 2014 18:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV8bRZ6zS4ib; Mon, 17 Feb 2014 18:51:41 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 630AB1A0309; Mon, 17 Feb 2014 18:51:39 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302ca3514f-f314f; Tue, 18 Feb 2014 10:49:26 +0800 (CST) X-RM-TRANSID: 2ee15302ca3514f-f314f Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15302ca357b8-15a94; Tue, 18 Feb 2014 10:49:26 +0800 (CST) X-RM-TRANSID: 2ee15302ca357b8-15a94 Date: Tue, 18 Feb 2014 10:51:37 +0800 From: "lizhenqiang@chinamobile.com" To: "Randy Bush" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <2014021810513701058825@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart260276176335_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/vjhMltOXegNadsZFLzmi-ero8MM Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 02:51:43 -0000 This is a multi-part message in MIME format. ------=_001_NextPart260276176335_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 CgoKCgoKVGVsbCBtZSBwbGVhc2UgdGhlIGxhcmdlIHByb3ZpZGVyIHRoYXQgeW91IGtub3cgaGFz IGhpcyBvd24gYXV0b21hdGljIGNvbmZpZ3VyYXRpb24gdG9vbHMuIEkgd291bGQgbGlrZSB0byBj b250YWN0IGhpbSB0byBsZWFybiBmcm9tIGhpbS6gCgoKCmxpemhlbnFpYW5nQGNoaW5hbW9iaWxl LmNvbQqgRnJvbTqgUmFuZHkgQnVzaERhdGU6oDIwMTQtMDItMTigMTA6NDBUbzqgbGl6aGVucWlh bmdAY2hpbmFtb2JpbGUuY29tQ0M6oGZhbnBlbmc7ICdpZHIgd2cnOyAnVjYgT3BzIExpc3QnOyAn Um9iZXJ0IFJhc3p1aydTdWJqZWN0OqBSZTogW0lkcl0gW3Y2b3BzXSBCR1AgSWRlbnRpZmllcj4g RG8geW91IGhhdmUgc3VjaCB0b29scyB0byBjb25maWcgeW91ciBuZXR3b3JrPyBPciBkbyB5b3Ug a25vdyB0aGUKPiB2ZW5kb3IgdGhhdCBwcm92aWRlIHN1Y2ggdG9vbHM/SW5kZWVkLCBzdWNooHBy b2dyYW1tYXRpYyBnZW5lcmF0aW9uCj4gdG9vbHMgYXJlIGdvb2QgZm9yIG5ldHdvcmsgcGxhbi4g QnV0IHRoZSBsb2dpYyBpbiB0aGUgdG9vbHMgaXMKPiBjb21wbGVjYXRlZCBlc3BlY2lhbGx5IGZv ciBhIHZlcnkgbGFyZ2UgbmV0d29yayB3aXRooGhpZXJhcmNoaWNhbAo+IG9wZXJhdGlvbiBhcyBQ ZW5nIEZhbiBtZW50aW9uZWQuCqAKdGhlcmUgYXJlIHByb2R1Y3RzIGluIHRoZSBzcGFjZSwgYnV0 IHRoZSBsYXJnZSBwcm92aWRlcnMgaSBrbm93IHdobwpjb25maWd1cmUgcHJvZ3JhbWF0aWNhbGx5 IGRldmVsb3BlZCB0aGVpciBvd24uoCB0aGVyZSBhcmUgbm90IGVub3VnaApsYXJnZSBwcm92aWRl cnMgbm90IHN1ZmZlcmluZyBmcm9tICdub3QgaW52ZW50ZWQgaGVyZScgdG8gbWFrZSBhCnJlYXNv bmFibGUgY3VzdG9tZXIgYmFzZSBmb3Igc2VyaW91cyBzb2Z0d2FyZSBkZXZlbG9wbWVudC4KoApi dXQgaXQgcGF5cyBmb3IgaXRzZWxmLCBzbyBzbWFydCBmb2xrIHdobyBkZXZlbG9wIGl0LgqgCnJh bmR5CqAKCg== ------=_001_NextPart260276176335_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Tell me please the large= provider that you know has his own automatic configuration tools. I would= like to contact him to learn from him. 
=0A
=0A
=0A
lizhenqiang@chinamobile.com
=0A=
 
From: Randy Bush
Date: 20= 14-02-18 10:40
Subject: Re: [Idr] [v6ops] BGP Identifier
=
> Do you have such tools to config your network? Or do you kn= ow the
=0A
> vendor that provide such tools?Indeed, such = programmatic generation
=0A
> tools are good for network plan.= But the logic in the tools is
=0A
> complecated especially fo= r a very large network with hierarchical
=0A
> operation = as Peng Fan mentioned.
=0A
 
=0A
there are products= in the space, but the large providers i know who
=0A
configure p= rogramatically developed their own.  there are not enough
=0Alarge providers not suffering from 'not invented here' to make a
= =0A
reasonable customer base for serious software development.
= =0A
 
=0A
but it pays for itself, so smart folk who deve= lop it.
=0A
 
=0A
randy
=0A
 
= =0A
=0A ------=_001_NextPart260276176335_=------ From nobody Mon Feb 17 19:17:24 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD071A0324; Mon, 17 Feb 2014 19:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuA7PNieCAYV; Mon, 17 Feb 2014 19:17:21 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD551A0309; Mon, 17 Feb 2014 19:17:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFbBJ-0002xU-TQ; Tue, 18 Feb 2014 03:17:15 +0000 Date: Tue, 18 Feb 2014 11:17:11 +0800 Message-ID: From: Randy Bush To: "lizhenqiang@chinamobile.com" In-Reply-To: <2014021810513701058825@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/W9Ja2_4J3qOLoYKAfkcZPlYKYes Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 03:17:23 -0000 > Tell me please the large provider that you know has his own automatic > configuration tools. l(3), ntt, ... > I would like to contact him to learn from him.=A0 it is considered secret sauce randy From nobody Mon Feb 17 19:34:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417BA1A05E9; Mon, 17 Feb 2014 19:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFva6gkiYfFo; Mon, 17 Feb 2014 19:33:50 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 6570E1A0309; Mon, 17 Feb 2014 19:33:45 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25302d41574b-5274b; Tue, 18 Feb 2014 11:31:33 +0800 (CST) X-RM-TRANSID: 2ee25302d41574b-5274b Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15302d4101b3-1656d; Tue, 18 Feb 2014 11:31:33 +0800 (CST) X-RM-TRANSID: 2ee15302d4101b3-1656d Date: Tue, 18 Feb 2014 11:33:44 +0800 From: "lizhenqiang@chinamobile.com" To: "Randy Bush" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <2014021811334398232342@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart745706857634_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/RlMqqOqttAC1PqRwbYK56_Qtpt0 Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 03:33:52 -0000 This is a multi-part message in MIME format. ------=_001_NextPart745706857634_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 CgoKCgoKU28gSSBoYXZlIHRvIGxlYXJuIHRvIHByb2dyYW0gbm93LiBJIGhvcGUgd2UgY291bGQg ZGV2ZWxvcCBvdXIgb3duIHRvb2xzLgoKCgpsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20KoEZy b206oFJhbmR5IEJ1c2hEYXRlOqAyMDE0LTAyLTE4oDExOjE3VG86oGxpemhlbnFpYW5nQGNoaW5h bW9iaWxlLmNvbUNDOqBmYW5wZW5nOyAnaWRyIHdnJzsgJ1Y2IE9wcyBMaXN0JzsgJ1JvYmVydCBS YXN6dWsnU3ViamVjdDqgUmU6IFtJZHJdIFt2Nm9wc10gQkdQIElkZW50aWZpZXI+IFRlbGwgbWUg cGxlYXNlIHRoZSBsYXJnZSBwcm92aWRlciB0aGF0IHlvdSBrbm93IGhhcyBoaXMgb3duIGF1dG9t YXRpYwo+IGNvbmZpZ3VyYXRpb24gdG9vbHMuCqAKbCgzKSwgbnR0LCAuLi4KoAo+IEkgd291bGQg bGlrZSB0byBjb250YWN0IGhpbSB0byBsZWFybiBmcm9tIGhpbS6gCqAKaXQgaXMgY29uc2lkZXJl ZCBzZWNyZXQgc2F1Y2UKoApyYW5keQqgCgo= ------=_001_NextPart745706857634_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
So I have to learn to pr= ogram now. I hope we could develop our own tools.
=0A

<= hr style=3D"width: 210px; height: 1px;" color=3D"#b5c4df" size=3D"1" align= =3D"left">=0A
=0A
lizhenqiang@chinamobile.com
=0A 
From: Randy Bush
Date: 2014-02-18=  11:17
Su= bject: Re: [Idr] [v6ops] BGP Identifier
> Tell me please the large provider that you know has his own automat= ic
=0A
> configuration tools.
=0A
 
=0Al(3), ntt, ...=0A
 
=0A
> I would like to cont= act him to learn from him. 
=0A
 
=0A
it is co= nsidered secret sauce
=0A
 
=0A
randy
=0A
=  
=0A=0A ------=_001_NextPart745706857634_=------ From nobody Mon Feb 17 19:55:16 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9E81A030F; Mon, 17 Feb 2014 19:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_622q1Of9kl; Mon, 17 Feb 2014 19:55:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CB0EF1A0129; Mon, 17 Feb 2014 19:55:09 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1I3t1Qa055188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 03:55:01 GMT (envelope-from joelja@bogus.com) Message-ID: <5302D994.1030801@bogus.com> Date: Mon, 17 Feb 2014 19:55:00 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: "lizhenqiang@chinamobile.com" , Christopher Morrow , Randy Bush References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , <006801cf2b34$22837cd0$678a7670$@chinamobile.com>, , <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com>, , <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com>, , <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com>, , <2014021810450694712020@chinamobile.com> In-Reply-To: <2014021810450694712020@chinamobile.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neMTn6Mn9OFbeD1QKP68CoWAKHeon6evk" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 18 Feb 2014 03:55:02 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/UWUqEzMquJ9HZcBcUhcgAo_dYlI Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 03:55:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --neMTn6Mn9OFbeD1QKP68CoWAKHeon6evk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/17/14, 6:45 PM, lizhenqiang@chinamobile.com wrote: >=20 >=20 >=20 >=20 >=20 >=20 > Thank you very much, Mr. Morrow. Yes, it is a good start. I will > contact Vijay for detail. However, I do not see the function that we > want from the slides. In fact, we also use some tools to assist our > network plan. However, the tools can not satisfy such complex > requirement. In a hierarchical operation network, the tools to > implement the logic we want is not a easy job. Zhenqiang Li We allocate ipv4 addresses today presumably, which implies the existence of business logic in basically all isps that accounts for the hierarchic allocation of 32 bit numbers. A brief cruise over to http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xht= ml Reveals a pool of at least 28 bits (a /4 in ipv4 land) worth of 32bit numbers that will never overlap with ipv4 unicast address assignments that you traditionally use for router-ids. embedding those in family iso addresses if you like seems harmless and you'll never accidentally configure one as a unicast address on an interface. it'll be a little while before I need 268 million bgp speaking routers in the same AS. >=20 > From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr > wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6ops] BGP > Identifierhttp://www.nanog.org/meetings/nanog44/presentations/Monday/Gi= ll_programatic_N44.pdf > > Mike's presentation (given by vijay) is a decent start... >=20 > On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush wrote: >>> Would you please give me an example about how modern large ISPs >>> manage their networks? >>=20 >> programmatic generation of configurations from databases. >>=20 >> randy >>=20 >> _______________________________________________ Idr mailing list=20 >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ Idr mailing list=20 > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >=20 >=20 >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --neMTn6Mn9OFbeD1QKP68CoWAKHeon6evk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMC2ZQACgkQ8AA1q7Z/VrJvLQCZAQ/rXdlRwA0wXsWzmiyz52pu qf8AoIcznighze83qe+VZuha4D98VlTi =VZ2G -----END PGP SIGNATURE----- --neMTn6Mn9OFbeD1QKP68CoWAKHeon6evk-- From nobody Mon Feb 17 20:35:10 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7861F1A055A; Mon, 17 Feb 2014 20:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0wtm_UtSavH; Mon, 17 Feb 2014 20:35:04 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 07F7C1A04B7; Mon, 17 Feb 2014 20:35:04 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1I4LNtp055332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 04:21:23 GMT (envelope-from joelja@bogus.com) Message-ID: <5302DFBD.1090105@bogus.com> Date: Mon, 17 Feb 2014 20:21:17 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: George Michaelson References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> <2014021810450694712020@chinamobile.com> <5302D994.1030801@bogus.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2D9odCIkxMX8RqjNN0sWm8Va8HF75saXI" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 18 Feb 2014 04:21:24 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/ottmyLqAyTYXvBk_CXAUKJvhHpI Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 04:35:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2D9odCIkxMX8RqjNN0sWm8Va8HF75saXI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/17/14, 8:12 PM, George Michaelson wrote: > 240/4 had drafts against it. NEVER is alas, not a normative word in wha= t > Joel said. I was refering to 224/4 which has a fairly toxic property with respect to it's reuse as ipv4 unicast... > Juniper already includes a flag to use 240/4 in cloud, at the request o= f a > cloud services company. yup... >=20 > On Tue, Feb 18, 2014 at 1:55 PM, joel jaeggli wrote:= >=20 >> On 2/17/14, 6:45 PM, lizhenqiang@chinamobile.com wrote: >>> >>> >>> >>> >>> >>> >>> Thank you very much, Mr. Morrow. Yes, it is a good start. I will >>> contact Vijay for detail. However, I do not see the function that we >>> want from the slides. In fact, we also use some tools to assist our >>> network plan. However, the tools can not satisfy such complex >>> requirement. In a hierarchical operation network, the tools to >>> implement the logic we want is not a easy job. Zhenqiang Li >> >> We allocate ipv4 addresses today presumably, which implies the existen= ce >> of business logic in basically all isps that accounts for the hierarch= ic >> allocation of 32 bit numbers. >> >> A brief cruise over to >> >> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.= xhtml >> >> Reveals a pool of at least 28 bits (a /4 in ipv4 land) worth of 32bit= >> numbers that will never overlap with ipv4 unicast address assignments >> that you traditionally use for router-ids. embedding those in family i= so >> addresses if you like seems harmless and you'll never accidentally >> configure one as a unicast address on an interface. it'll be a little >> while before I need 268 million bgp speaking routers in the same AS. >> >> >>> >>> From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr >>> wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6ops] BGP >>> Identifierhttp:// >> www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N= 44.pdf >>> >>> Mike's presentation (given by vijay) is a decent start... >>> >>> On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush wrote: >>>>> Would you please give me an example about how modern large ISPs >>>>> manage their networks? >>>> >>>> programmatic generation of configurations from databases. >>>> >>>> randy >>>> >>>> _______________________________________________ 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 >>> >>> >>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >=20 --2D9odCIkxMX8RqjNN0sWm8Va8HF75saXI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMC370ACgkQ8AA1q7Z/VrKl7gCfXwpsK0vHthY0GTmMUa8f67z+ /MAAnA+ETxIWnNC1kpzPUXbLuOx6GdxL =H9BK -----END PGP SIGNATURE----- --2D9odCIkxMX8RqjNN0sWm8Va8HF75saXI-- From nobody Mon Feb 17 20:44:03 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FC11A05ED; Mon, 17 Feb 2014 20:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVPD9v2zT7ix; Mon, 17 Feb 2014 20:43:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5A31A05EB; Mon, 17 Feb 2014 20:43:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFcX7-00038T-8F; Tue, 18 Feb 2014 04:43:49 +0000 Date: Tue, 18 Feb 2014 12:43:46 +0800 Message-ID: From: Randy Bush To: "Fan, Peng" In-Reply-To: <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jGnL3zHTNSZjG31vBq-8Iv4-ajc Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 04:44:00 -0000 > Just to clarify. I am not complaining we cannot assign the unique integers, > but the integers require additional planning but 32 bit integers should require only 1/4 the planning as 128 bit integers :) you allocate v4/v6 addresses hierarchically. so take 240/whatever and allocate using the same system. randy From nobody Mon Feb 17 22:08:34 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8121A05FD; Mon, 17 Feb 2014 22:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GoVOyozubEa; Mon, 17 Feb 2014 22:08:22 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A58CC1A03E7; Mon, 17 Feb 2014 22:08:21 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302f84b6ad-f66ad; Tue, 18 Feb 2014 14:06:03 +0800 (CST) X-RM-TRANSID: 2ee15302f84b6ad-f66ad Received: from X6X8D79D8F49E2 (unknown[10.2.43.104]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee25302f84b837-f786b; Tue, 18 Feb 2014 14:06:03 +0800 (CST) X-RM-TRANSID: 2ee25302f84b837-f786b From: "Fan, Peng" To: "'Christopher Morrow'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> In-Reply-To: Date: Tue, 18 Feb 2014 14:09:30 +0800 Message-ID: <00dc01cf2c6f$fcce3c40$f66ab4c0$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QKQBeNnAdstUIkBXjGXJpkRA7Iw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/idr/hfHIC6zIfxN-7mMeql89c9KP2KM Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 06:08:25 -0000 Hi Christopher, Normally it is easier to handle routers within the AS as we have full control over it. I think the key point is the ASBR, as we have no control of its eBGP peers. A simple approach is to enable both this extension and RFC6286, and assign a 32-bit ID in addition to the 128-bit one for backup purpose before we are aware of the capability of its peers. The ASBR prefers the 128-bit ID. Since the ID field of OPEN message sent by the ASBR is zero, which will result in a "bad bgp identifier" error message sent by the peer if it does not support the new 128-bit ID capability, the ASBR will know the type of its peer. The ASBR can initiate a second connection in the old way, and the connection falls back using 32-bit ID. Peng > -----Original Message----- > From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] > On Behalf Of Christopher Morrow > Sent: Tuesday, February 18, 2014 11:42 AM > To: lizhenqiang@chinamobile.com > Cc: Randy Bush; Farmer; jaeggli; Amante; JAMES; Doering; Raszuk'; fanpeng; idr > wg; V6 Ops List > Subject: Re: Re: [Idr] [v6ops] BGP Identifier > > On Mon, Feb 17, 2014 at 10:30 PM, lizhenqiang@chinamobile.com > wrote: > > Hi All, > > > > Thank you all for your valuable comments and interests in this draft. > > Any technical concerns about the draft? Is there someone in the mail > > list from operators that has the same problem as me? > > > > i think shane's point about 'make a stab at transition technique' > still needs to be dealt with, yes? > > and really... I don't see a huge reason to do this anyway, yet. > > > Many Thanks, > > Zhenqiang Li > > > > ________________________________ > > From nobody Mon Feb 17 22:08:39 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DFC1A03E7; Mon, 17 Feb 2014 22:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jwl4FTH53gkH; Mon, 17 Feb 2014 22:08:29 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id A7C341A0358; Mon, 17 Feb 2014 22:08:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFdqv-0003FJ-6J; Tue, 18 Feb 2014 06:08:22 +0000 Date: Tue, 18 Feb 2014 14:08:17 +0800 Message-ID: From: Randy Bush To: Peng Fan In-Reply-To: <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/kkXwkyb0usE2wCIzEDieYVDyvPk Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 06:08:33 -0000 Christopher Morrow Farmer jaeggli Amante JAMES Doering > Normally it is easier to handle routers within the AS as we have full > control over it. I think the key point is the ASBR, as we have no > control of its eBGP peers. A simple approach is to enable both this > extension and RFC6286, and assign a 32-bit ID in addition to the > 128-bit one for backup purpose before we are aware of the capability > of its peers. The ASBR prefers the 128-bit ID. Since the ID field of > OPEN message sent by the ASBR is zero, which will result in a "bad bgp > identifier" error message sent by the peer if it does not support the > new 128-bit ID capability, the ASBR will know the type of its > peer. The ASBR can initiate a second connection in the old way, and > the connection falls back using 32-bit ID. what we have here is a bunch of network operators trying to help you design and configure your network. it may have gone past the amusing and educational for the non-op ietf folk on these lists. you may get wider and deeper free consulting, with 42 conflicting opinions, by moving this to nanog, apops, ... list(s). randy From nobody Tue Feb 18 01:41:38 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FBE1A0604 for ; Tue, 18 Feb 2014 01:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaHl1te1lADN for ; Tue, 18 Feb 2014 01:41:28 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C96471A05E8 for ; Tue, 18 Feb 2014 01:41:27 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 4305818C25E; Tue, 18 Feb 2014 10:41:24 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0E2E935C069; Tue, 18 Feb 2014 10:41:24 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 18 Feb 2014 10:41:22 +0100 From: To: "Saikat Ray (sairay)" , Robert Raszuk Date: Tue, 18 Feb 2014 10:41:21 +0100 Thread-Topic: [Idr] Flowspec, coexistance of redirect and mirror actions Thread-Index: AQHOo/436d64LadntUuqPTw52t2IbJqxhuZggAixvVCAAM664IAAaGcA//+fjyCAAMI18A== Message-ID: <27431_1392716484_53032AC4_27431_3232_1_EEE55384044474429A926C625D0FCC810C340A35AD@PUEXCB2F.nanterre.francetelecom.fr> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> <8ED5B0B0F5B4854A912480C1521F973A11B2B080@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A11B2B12C@xmb-rcd-x13.cisco.com> In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A11B2B12C@xmb-rcd-x13.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810C340A35ADPUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.17.104815 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/wcnXmXd5rfTE2ZbJbHbEYBtDAY0 Cc: "mtexier@arbor.net" , "idr@ietf.org" , Jeff Haas , "David Smith \(djsmith\)" , "ju1738@att.com" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 09:41:35 -0000 --_000_EEE55384044474429A926C625D0FCC810C340A35ADPUEXCB2Fnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This may not be a good solution to rely on nexthop field . Something simila= r to VRF Redirect may be better (encode redirect IP in the community) and m= ay permit to use multiple instance of the community. It's important to keep FIB check to ensure reachability to the encoded IP. De : Saikat Ray (sairay) [mailto:sairay@cisco.com] Envoy=E9 : lundi 17 f=E9vrier 2014 23:03 =C0 : Robert Raszuk Cc : LITKOWSKI Stephane DTF/DERX; Bertrand Duvivier (bduvivie); Pradosh Moh= apatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith (djsmi= th); Jeff Haas Objet : RE: [Idr] Flowspec, coexistance of redirect and mirror actions I was referring to draft-simpson-idr-flowspec-redirect. "The filter entry matches the IP packets described in the NLRI field and redirects them (C=3D0) or copies them (C=3D1) towards the IPv4 or IPv6 address specified in the 'Network Address of Next- Hop' field of the associated MP_REACH_NLRI." I assumed this thread is for draft-simpson-idr-flowspec-redirect since that= is what the first email in the thread refers to. From: rraszuk@gmail.com [mailto:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk Sent: Monday, February 17, 2014 1:46 PM To: Saikat Ray (sairay) Cc: stephane.litkowski@orange.com; Be= rtrand Duvivier (bduvivie); Pradosh Mohapatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith (djsmith); Jeff Haas Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Saikat, Flowspec RFC5575 is not using next hop for it's actions. In fact BGP NEXT_H= OP is optional. A given flow may be associated with a set of attributes, depending on the particular application; such attributes may or may not include reachability information (i.e., NEXT_HOP) Instead we use the RT match to determine which local VRF is used for redire= ct or mirror. Stephane's proposal is wise IMO as we could list different VR= Fs one for each required action. The forwarding or encapsulation itself is = defined in those redirect/mirror VRFs. Redirect: The redirect extended community allows the traffic to be redirected to a VRF routing instance that lists the specified route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This extended community uses the same encoding as the Route Target extended community [RFC4360]. Best, R. On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay) > wrote: A given update (a BGP path) has only one NEXTHOP (the NEXTHOP determines wh= ere to redirect or mirror the packets). From: Idr [mailto:idr-bounces@ietf.org] On Beh= alf Of stephane.litkowski@orange.com Sent: Monday, February 17, 2014 1:19 AM To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra Cc: mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith (djsmith); Jeff= Haas Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi, In order to have both actions applied, why not setting twice time the extco= mmunity in the BGP update ? (one with C=3D0 and one with C=3D1). Does this cause any issue ? Applying multiple actions by setting multiple extcts seems to be authorized= , so why not using the same thing here by setting twice time the same extct= with different C flag. Otherwise need to split it in two different extcts. Thoughts ? Best Regards, Stephane De : Idr [mailto:idr-bounces@ietf.org] De la part de Bertrand Duvivier (bdu= vivie) Envoy=E9 : mardi 11 f=E9vrier 2014 21:39 =C0 : Robert Raszuk; Pradosh Mohapatra Cc : mtexier@arbor.net; idr@ietf.org; ju1738@att.com; Jeff Haas; David Smith (dj= smith) Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi, I see 2 cases: Signaling primary/backup actions We could control path priority using LP or MED. Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ... Of N path RR could select best 2 or 3 or all best path based on preferred = LP (or MED) BGP Client could select first action, if not possible due to NH not availab= le in RIB, then act on second ... etc... Signaling multiple parallel actions. I don't have answer for this one Bertrand From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of Robert Raszuk Sent: mercredi 28 ao=FBt 2013 16:52 To: Pradosh Mohapatra Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); ju1738@att.com Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Hi Pradosh, 5575 still requires you to run BGP best path selection even if you have mul= tiple paths. This is both for the onward advertisement as well as for the l= ocal installation. You are proposing to install more then "best" path locally which may actual= ly require substantial changes to the BGP operation. How do you control which paths are to be installed let's say which 2 out of= N ? The multipath checks are not really helpful here. It's an interesting question if we in general agree to install multiple pat= hs in flowspec SAFI for the exact same NLRI ? Regards, R. On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra > wrote: Hi Kaliraj, Suggest you use add-path: send two paths for the flow, one with next-hop X and redirect action, the other with next-hop Y and mirror action. - Pradosh ________________________________ From: Kaliraj Vairavakkalai > To: "Simpson, Adam (Adam)" >; "ju1738@att.com" >; "pmohapat@cisco.com" >; "djsmith@cisco.com" >; "H= enderickx, Wim (Wim)" >; "mtexier@arbor.net" > Cc: Jeff Haas >; "idr@ietf.org<= mailto:idr@ietf.org>" > Sent: Tuesday, August 27, 2013 10:55 AM Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Yes Adam, the original flow with destination A is steered/moved to new dest= ination B (e.g. scrubber device) while simultaneously copy of this flow sen= t to a new destination C (e.g. for LI) The devices doing the scrubbing and LI may be different (based on devices' = capability, load-balancing requirement etc), was the thought behind my ques= tion. Thanks, Kaliraj > -----Original Message----- > From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] > Sent: Tuesday, August 27, 2013 10:19 AM > To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapa= t@cisco.com; > djsmith@cisco.com; Henderickx, Wim (Wim); mtexi= er@arbor.net > Cc: Jeff Haas; idr@ietf.org > Subject: Re: Flowspec, coexistance of redirect and mirror actions > > Hi Kaliraj, > > You are correct; these actions are mutually exclusive according to the cu= rrent > encoding. What does it mean for you to have a flow both moved > (redirected) and copied (mirrored)? Do you mean the original flow with > destination A is steered/moved to new destination B while at the same tim= e a > copy of this flow is sent to a new destination C? I personally have not s= een a > requirement for this type of compound action but I will leave the other > authors to comment as well. > > -Adam > > > On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" > wrote: > > >Hi authors, > > > >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 > > > >If it is desired to perform both "redirect-action" to a nexthop X, and > >"mirror-action" to a different nexthop Y simultaneously for the same > >flow, how is it achieved? > > > >It appears the signaling for such a scenario may not be handled by the > >mechanisms specified in this draft, unless I am missing something. > >Could you pls clarify. > > > >Thanks > >Kaliraj > > > > _______________________________________________ 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810C340A35ADPUEXCB2Fnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This may not be a good solution to rely on nexthop field . Something= similar to VRF Redirect may be better (encode redirect IP in the community= ) and may permit to use multiple instance of the community.

It’s important to keep= FIB check to ensure reachability to the encoded IP.

<= p class=3DMsoNormal>

 

De : Saikat Ray (sairay) [mailto:sairay@cisco.com]
= Envoy=E9 : lundi 17 f=E9vrier 2014 23:03
=C0 : R= obert Raszuk
Cc : LITKOWSKI Stephane DTF/DERX; Bertrand Duvi= vier (bduvivie); Pradosh Mohapatra; mtexier@arbor.net; idr@ietf.org; ju1738= @att.com; David Smith (djsmith); Jeff Haas
Objet : RE: [Idr]= Flowspec, coexistance of redirect and mirror actions

=

 

= I was referring to draft-simpson-idr-flowspec-redirect.

 

“The filter entry matches the IP packets des= cribed in

   the NLRI field and redirects them (C=3D0) = or copies them (C=3D1) towards<= /p>

   the IPv4 or IPv6 addr= ess specified in the 'Network Address of Next-

   Hop' = field of the associated MP_REACH_NLRI.”

 

I = assumed this thread is for draft-simpson-idr-flowspec-redirect since that i= s what the first email in the thread refers to.

 

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Beha= lf Of Robert Raszuk
Sent: Monday, February 17, 2014 1:46 PMTo: Saikat Ray (sairay)
Cc: stephane.litkowski@orange.com; Bertrand Duvivier (= bduvivie); Pradosh Mohapatra; mtexier@= arbor.net; idr@ietf.org; ju1738@att.com; David Smith (djsmith); Jeff Haa= s
Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror= actions

 

Saikat,<= span lang=3DEN-US>

 

Flowspec RFC5575 is not using = next hop for it's actions. In fact BGP NEXT_HOP is optional. 

 

   A given flow may be associated w=
ith a set of attributes, depending on<=
/span>
=
   the particular application; such attributes may or may not inc=
lude
   reachability informa=
tion (i.e., NEXT_HOP)
 
 
I=
nstead we use the RT match to determine which local VRF is used for redirec=
t or mirror. Stephane's proposal is wise IMO as we could list different VRF=
s one for each required action. The forwarding or encapsulation itself is d=
efined in those redirect/mirror VRFs.


 
    &nb=
sp; Redirect:  The redirect extended community allows the traffic to b=
e
      redir=
ected to a VRF routing instance that lists the specified
      route-target in its imp=
ort policy.  If several local instances=

      match this criteria, the choice betwe=
en them is a local matter
= 
  =
    (for example, the instance with the lowest Route Disting=
uisher
      =
value can be elected).  This extended community uses the same
      encoding as the=
 Route Target extended community [RFC4360=
].
 
 
Best,
R.
 <= span lang=3DEN-US>
 
&=
nbsp;
 =

 

On Mon, Feb 17, 2014 at 10:33 PM, Saikat= Ray (sairay) <sai= ray@cisco.com> wrote:

A given update (a BGP path) has only one NEXTHOP (the NEXTHOP dete= rmines where to redirect or mirror the packets). =

 

From: Idr [mailto:id= r-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Monday, February 17, 2014 1:19 AM
To: Bertrand Duvivie= r (bduvivie); Robert Raszuk; Pradosh Mohapatra
Cc: mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith (djsmith)= ; Jeff Haas


Subject: Re: [Idr] Flowspec, c= oexistance of redirect and mirror actions

=

 

Hi,

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

In order to have both actions applied, why not setting twice ti= me the extcommunity in the BGP update ? (one with C=3D0 and one with C=3D1)= .

Does this cause any issue ?

 

Applying multiple actions by setting mult= iple extcts seems to be authorized, so why not using the same thing here by= setting twice time the same extct with different C flag. Otherwise need to= split it in two different extcts.

 

Thoughts ?

 

 

Best Regard= s,

 

Stephane

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'> 

 =

 

Hi, =

 <= /span>

I see 2 cases: <= /p>

 

Signaling primary/backup actions

 

We could control path priority using LP or MED.

Assuming NLRI x PATH = 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, …

 

Of N path RR cou= ld select best 2 or 3 or all best path  based on preferred LP (or MED)=

BGP Client could select first action, if not possible due to NH not availa= ble in RIB, then act on second … etc…

 

Signaling mult= iple parallel actions.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

I don’t have answer for this one

&nbs= p;

Bertrand

 

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'> 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of= Robert Raszuk
Sent: mercredi 28 ao=FBt 2013 16:52
To:<= /b> Pradosh Mohapatra
Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); ju1738@att.com
Subje= ct: Re: [Idr] Flowspec, coexistance of redirect and mirror actions

 =

Hi Pradosh,<= /p>

 

<= span lang=3DEN-US style=3D'font-family:"Courier New"'>5575 still requires y= ou to run BGP best path selection even if you have multiple paths. This is = both for the onward advertisement as well as for the local installation.&nb= sp;

 

You are proposing to install more then "best= " path locally which may actually require substantial changes to the B= GP operation. 

 

How do you control which paths ar= e to be installed let's say which 2 out of N ? The multipath checks are not= really helpful here. 

=

&n= bsp;

It's an interesting quest= ion if we in general agree to install multiple paths in flowspec SAFI for t= he exact same NLRI ? 

<= /div>

&nb= sp;

Regards,

R.

 

 

 

 

=

 =

 

 

On Tue, Aug 27, 2013 at 11:37 PM, Pr= adosh Mohapatra <mpradosh@yahoo.com> wrote:

Hi Kaliraj,

<= span lang=3DEN-US> 

Suggest you use add-path: send two paths for the flow, one with ne= xt-hop X 

= and redirect action, the other with next-hop Y and mirror action.

 

- Pradosh

 

From:<= /span> Ka= liraj Vairavakkalai <kaliraj@juniper.net>
To: "Simpson, Adam (Adam)&= quot; <adam.simpson@alcatel-lucent.com>; "ju1738@att.com" <ju1738@att.com>; "pmohapat@cisco.com" &= lt;pmohapat@cisco.c= om>; "dj= smith@cisco.com" <djsmith@cisco.com>; "Henderickx, Wim (Wim)" &l= t;wi= m.henderickx@alcatel-lucent.com>; "mtexier@arbor.net" <mtexier@arbor.net>
Cc:= Jeff Haas <j= haas@juniper.net>; "idr@ietf.org" <idr@ietf.org>
Sent: Tuesday, August 27, 2013 10:= 55 AM
Subject: Re: [Idr] Flowspec, coexistance of redirect and mi= rror actions


Yes Adam, the original flow with destination = A is steered/moved to new destination B (e.g. scrubber device) while simult= aneously copy of this flow sent to a new destination C (e.g. for LI)
The devices doing the scrubbing and LI may be different (based on devices= ' capability, load-balancing requirement etc), was the thought behind my qu= estion.

Thanks,
Kaliraj
> -----Original Message-----
= > From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com]
&= gt; Sent: Tuesday, August 27, 2013 10:19 AM
> To: Kaliraj Vairavakkal= ai; ju1738@att.com;= pmohapat@cisco.com= ;
> djsmit= h@cisco.com; Henderickx, Wim (Wim); mtexier@arbor.net
> Cc: Jeff Haas; idr@ietf.org
> Subject: R= e: Flowspec, coexistance of redirect and mirror actions
>
> Hi= Kaliraj,
>
> You are correct; these actions are mutually excl= usive according to the current
> encoding. What does it mean for you = to have a flow both moved
> (redirected) and copied (mirrored)? Do yo= u mean the original flow with
> destination A is steered/moved to new= destination B while at the same time a
> copy of this flow is sent t= o a new destination C? I personally have not seen a
> requirement for= this type of compound action but I will leave the other
> authors to= comment as well.
>
> -Adam
>
>
> On 2013-= 08-25 1:13 AM, "Kaliraj Vairavakkalai" <kaliraj@juniper.net> wrote:
&g= t;
> >Hi authors,
> >
> >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02> >
> >If it is desired to perform both "redirect-act= ion" to a nexthop X, and
> >"mirror-action" to a di= fferent nexthop Y simultaneously for the same
> >flow, how is it a= chieved?
> >
> >It appears the signaling for such a scena= rio may not be handled by the
> >mechanisms specified in this draf= t, unless I am missing something.
> >Could you pls clarify.
>= ; >
> >Thanks
> >Kaliraj
> >
>
>=


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

<= /div>


________________= _______________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman= /listinfo/idr

&nbs= p;

________________________________________=
___________________________________________________________________________=
______
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploite=
s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu=
illez le signaler
a l'expedi=
teur et le detruire ainsi que les pieces jointes. Les messages electronique=
s etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, defo=
rme ou falsifie. Merci.
&nbs=
p;
This message and its atta=
chments may contain confidential or privileged information that may be prot=
ected by law;
they should no=
t be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, pleas=
e notify the sender and delete this message and its attachments.
As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.
Thank you.

 

_______________=
___________________________________________________________________________=
_______________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_EEE55384044474429A926C625D0FCC810C340A35ADPUEXCB2Fnante_-- From nobody Tue Feb 18 01:48:37 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CF01A0466 for ; Tue, 18 Feb 2014 01:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGHbcFqgVPFJ for ; Tue, 18 Feb 2014 01:48:32 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EA3431A0126 for ; Tue, 18 Feb 2014 01:48:31 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id u14so12072213lbd.15 for ; Tue, 18 Feb 2014 01:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Rmg1ST4Ma5dofK09cOCypbnTi85JxAm548s32eZ+zSQ=; b=TDRywJr34lm38b4bVDjePmJlVSoULGZLC39MoZdDgocZyHO1LDKIqNTdOCddylhocB pn97wFBuDPn1sCOEgA3NagDDGTh4LwtZIXP447OBUFFtzMMFIUOQ3cin6fOeoc7F5yYe fqBf0HC0zEChsuOB8xs9xDHfBt1EejOnP851l1D7PiXfUYkfqY7Ejjl9x6rvuQ1OBwOX 1eaauF9I6wRaq2uQGj0F4K0J3JAW01oagiRrF7xmsDTyzFiiFiDxU6ANIbWo9GoSbYQQ 075Z7QQfsuSIwecspmS/pzDykISRh6U490o0V9euMt5HkByi2TfE7ANH7iO4/cCDJ7TT lcPQ== MIME-Version: 1.0 X-Received: by 10.152.28.200 with SMTP id d8mr733362lah.59.1392716908324; Tue, 18 Feb 2014 01:48:28 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.51.105 with HTTP; Tue, 18 Feb 2014 01:48:28 -0800 (PST) In-Reply-To: <27431_1392716484_53032AC4_27431_3232_1_EEE55384044474429A926C625D0FCC810C340A35AD@PUEXCB2F.nanterre.francetelecom.fr> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> <8ED5B0B0F5B4854A912480C1521F973A11B2B080@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A11B2B12C@xmb-rcd-x13.cisco.com> <27431_1392716484_53032AC4_27431_3232_1_EEE55384044474429A926C625D0FCC810C340A35AD@PUEXCB2F.nanterre.francetelecom.fr> Date: Tue, 18 Feb 2014 10:48:28 +0100 X-Google-Sender-Auth: OBcgeTqrCTJ29c9PVZ-SjiOSf0E Message-ID: From: Robert Raszuk To: "" , "Saikat Ray (sairay)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/orO18mcFkjEBMFO2h_n0KN7AcVg Cc: "mtexier@arbor.net" , "idr@ietf.org" , Jeff Haas , "David Smith \(djsmith\)" , "ju1738@att.com" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 09:48:36 -0000 It is more then that ... The reason Pedro and I originally chosen to go via VRF was precisely to avoid distributing encapsulation destination(s) as well as encapsulation types within the flow spec routes leaving it to local (special) VRF. Moreover some PEs may have locally attached inspection devices so it would be impossible to universally send such redirect destination action via p2mp protocol. If authors of the new draft insist on the embedded redirect/mirror destination I would highly recommend not to use the "global" next hop from MP-REACH but to allow space to carry one within the action instructions. That way one could use different address for different actions. Regards, R. On Tue, Feb 18, 2014 at 10:41 AM, wrote: > This may not be a good solution to rely on nexthop field . Something simi= lar > to VRF Redirect may be better (encode redirect IP in the community) and m= ay > permit to use multiple instance of the community. > > It's important to keep FIB check to ensure reachability to the encoded IP= . > > > > De : Saikat Ray (sairay) [mailto:sairay@cisco.com] > Envoy=E9 : lundi 17 f=E9vrier 2014 23:03 > =C0 : Robert Raszuk > Cc : LITKOWSKI Stephane DTF/DERX; Bertrand Duvivier (bduvivie); Pradosh > Mohapatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith > (djsmith); Jeff Haas > Objet : RE: [Idr] Flowspec, coexistance of redirect and mirror actions > > > > I was referring to draft-simpson-idr-flowspec-redirect. > > > > "The filter entry matches the IP packets described in > > the NLRI field and redirects them (C=3D0) or copies them (C=3D1) towar= ds > > the IPv4 or IPv6 address specified in the 'Network Address of Next- > > Hop' field of the associated MP_REACH_NLRI." > > > > I assumed this thread is for draft-simpson-idr-flowspec-redirect since th= at > is what the first email in the thread refers to. > > > > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Monday, February 17, 2014 1:46 PM > To: Saikat Ray (sairay) > Cc: stephane.litkowski@orange.com; Bertrand Duvivier (bduvivie); Pradosh > Mohapatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith > (djsmith); Jeff Haas > Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions > > > > Saikat, > > > > Flowspec RFC5575 is not using next hop for it's actions. In fact BGP > NEXT_HOP is optional. > > > > A given flow may be associated with a set of attributes, depending on > > the particular application; such attributes may or may not include > > reachability information (i.e., NEXT_HOP) > > > > > > Instead we use the RT match to determine which local VRF is used for > redirect or mirror. Stephane's proposal is wise IMO as we could list > different VRFs one for each required action. The forwarding or encapsulat= ion > itself is defined in those redirect/mirror VRFs. > > > > > Redirect: The redirect extended community allows the traffic to be > > redirected to a VRF routing instance that lists the specified > > route-target in its import policy. If several local instances > > match this criteria, the choice between them is a local matter > > (for example, the instance with the lowest Route Distinguisher > > value can be elected). This extended community uses the same > > encoding as the Route Target extended community [RFC4360]. > > > > > > Best, > > R. > > > > > > > > > > > > On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay) > wrote: > > A given update (a BGP path) has only one NEXTHOP (the NEXTHOP determines > where to redirect or mirror the packets). > > > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of > stephane.litkowski@orange.com > Sent: Monday, February 17, 2014 1:19 AM > To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra > Cc: mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith (djsmith= ); > Jeff Haas > > > Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions > > > > Hi, > > > > In order to have both actions applied, why not setting twice time the > extcommunity in the BGP update ? (one with C=3D0 and one with C=3D1). > > Does this cause any issue ? > > > > Applying multiple actions by setting multiple extcts seems to be authoriz= ed, > so why not using the same thing here by setting twice time the same extct > with different C flag. Otherwise need to split it in two different extcts= . > > > > Thoughts ? > > > > > > Best Regards, > > > > Stephane > > > > > > De : Idr [mailto:idr-bounces@ietf.org] De la part de Bertrand Duvivier > (bduvivie) > Envoy=E9 : mardi 11 f=E9vrier 2014 21:39 > =C0 : Robert Raszuk; Pradosh Mohapatra > Cc : mtexier@arbor.net; idr@ietf.org; ju1738@att.com; Jeff Haas; David Sm= ith > (djsmith) > Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror actions > > > > Hi, > > > > I see 2 cases: > > > > Signaling primary/backup actions > > > > We could control path priority using LP or MED. > > Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ... > > > > Of N path RR could select best 2 or 3 or all best path based on preferre= d > LP (or MED) > > BGP Client could select first action, if not possible due to NH not > available in RIB, then act on second ... etc... > > > > Signaling multiple parallel actions. > > > > I don't have answer for this one > > > > Bertrand > > > > > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rob= ert > Raszuk > Sent: mercredi 28 ao=FBt 2013 16:52 > To: Pradosh Mohapatra > Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); > ju1738@att.com > Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions > > > > Hi Pradosh, > > > > 5575 still requires you to run BGP best path selection even if you have > multiple paths. This is both for the onward advertisement as well as for = the > local installation. > > > > You are proposing to install more then "best" path locally which may > actually require substantial changes to the BGP operation. > > > > How do you control which paths are to be installed let's say which 2 out = of > N ? The multipath checks are not really helpful here. > > > > It's an interesting question if we in general agree to install multiple > paths in flowspec SAFI for the exact same NLRI ? > > > > Regards, > > R. > > > > > > > > > > > > > > > > On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra > wrote: > > Hi Kaliraj, > > > > Suggest you use add-path: send two paths for the flow, one with next-hop = X > > and redirect action, the other with next-hop Y and mirror action. > > > > - Pradosh > > > > ________________________________ > > From: Kaliraj Vairavakkalai > To: "Simpson, Adam (Adam)" ; > "ju1738@att.com" ; "pmohapat@cisco.com" > ; "djsmith@cisco.com" ; "Henderick= x, > Wim (Wim)" ; "mtexier@arbor.net" > > Cc: Jeff Haas ; "idr@ietf.org" > Sent: Tuesday, August 27, 2013 10:55 AM > Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions > > > Yes Adam, the original flow with destination A is steered/moved to new > destination B (e.g. scrubber device) while simultaneously copy of this fl= ow > sent to a new destination C (e.g. for LI) > > The devices doing the scrubbing and LI may be different (based on devices= ' > capability, load-balancing requirement etc), was the thought behind my > question. > > Thanks, > Kaliraj >> -----Original Message----- >> From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] >> Sent: Tuesday, August 27, 2013 10:19 AM >> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com; >> djsmith@cisco.com; Henderickx, Wim (Wim); mtexier@arbor.net >> Cc: Jeff Haas; idr@ietf.org >> Subject: Re: Flowspec, coexistance of redirect and mirror actions >> >> Hi Kaliraj, >> >> You are correct; these actions are mutually exclusive according to the >> current >> encoding. What does it mean for you to have a flow both moved >> (redirected) and copied (mirrored)? Do you mean the original flow with >> destination A is steered/moved to new destination B while at the same ti= me >> a >> copy of this flow is sent to a new destination C? I personally have not >> seen a >> requirement for this type of compound action but I will leave the other >> authors to comment as well. >> >> -Adam >> >> >> On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" >> wrote: >> >> >Hi authors, >> > >> >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 >> > >> >If it is desired to perform both "redirect-action" to a nexthop X, and >> >"mirror-action" to a different nexthop Y simultaneously for the same >> >flow, how is it achieved? >> > >> >It appears the signaling for such a scenario may not be handled by the >> >mechanisms specified in this draft, unless I am missing something. >> >Could you pls clarify. >> > >> >Thanks >> >Kaliraj >> > >> >> > > > _______________________________________________ > 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 > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > > Thank you. > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. From nobody Tue Feb 18 03:27:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7791B1A0465; Tue, 18 Feb 2014 03:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.147 X-Spam-Level: X-Spam-Status: No, score=-4.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHLimx39XGwl; Tue, 18 Feb 2014 03:27:43 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 445301A032F; Tue, 18 Feb 2014 03:27:43 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id ca343035.2ac0a9e15940.3337058.00-2450.9318766.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 18 Feb 2014 11:27:40 +0000 (UTC) X-MXL-Hash: 530343ac3a911ade-508fec8aad0a3c44fdb345807df4168738e7a646 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 9a343035.0.3337043.00-2065.9318731.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 18 Feb 2014 11:27:39 +0000 (UTC) X-MXL-Hash: 530343ab24a610f0-f0f231d518e35646c895d843c1f78424984fca40 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IBRbYE024965; Tue, 18 Feb 2014 06:27:37 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IBRSHZ024883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 06:27:29 -0500 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 18 Feb 2014 11:27:17 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 06:27:16 -0500 From: "UTTARO, JAMES" To: "lizhenqiang@chinamobile.com" , Randy Bush Thread-Topic: [Idr] [v6ops] BGP Identifier Thread-Index: AQHPLFRXkH+sv9yQ+kSGj1ZIvBEoEZq63y+g Date: Tue, 18 Feb 2014 11:27:16 +0000 Message-ID: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, <2014021810513701058825@chinamobile.com> In-Reply-To: <2014021810513701058825@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.79.159] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F06341989MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=k0ITYs5nkwcA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=e_BCuZGg8NsA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=R5C9hjxsAAAA:8 a=No5EcEP4AAAA:8 a=2clOPd4PAAAA:8 a] X-AnalysisOut: [=dVGEDVYWMja6ID64LnkA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:1] X-AnalysisOut: [0 a=hFj-Mf0cM8IA:10 a=PKgchsl1YdkA:10 a=bDUki_mJ7DgA:10 a=] X-AnalysisOut: [yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L] X-AnalysisOut: [4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=OK47xdkk6A] X-AnalysisOut: [psxbyL:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/idr/lmwp5xyjp63vtcKa4AHoljAAW7g Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 11:27:46 -0000 --_000_B17A6910EEDD1F45980687268941550F06341989MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have developed numerous configuration tools that create/mod PE, RR confi= gs. We also have lots of tools that speak to the network in a live sense to= get health, stats ... All of the raw material is readily available. TBH I = cannot speak to you about our solutions in anymore depth.. Jim Uttaro From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of lizhenqiang@chinamobil= e.com Sent: Monday, February 17, 2014 9:52 PM To: Randy Bush Cc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier Tell me please the large provider that you know has his own automatic confi= guration tools. I would like to contact him to learn from him. ________________________________ lizhenqiang@chinamobile.com From: Randy Bush Date: 2014-02-18 10:40 To: lizhenqiang@chinamobile.com CC: fanpeng; 'idr wg';= 'V6 Ops List'; 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier > Do you have such tools to config your network? Or do you know the > vendor that provide such tools?Indeed, such programmatic generation > tools are good for network plan. But the logic in the tools is > complecated especially for a very large network with hierarchical > operation as Peng Fan mentioned. there are products in the space, but the large providers i know who configure programatically developed their own. there are not enough large providers not suffering from 'not invented here' to make a reasonable customer base for serious software development. but it pays for itself, so smart folk who develop it. randy --_000_B17A6910EEDD1F45980687268941550F06341989MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have developed numerou= s configuration tools that create/mod PE, RR configs. We also have lots of = tools that speak to the network in a live sense to get health, stats … All of the raw material is readily available. TBH I cannot s= peak to you about our solutions in anymore depth..

 <= /p>

Jim Uttaro

 <= /p>

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of lizhenqiang@chinamobile.com
Sent: Monday, February 17, 2014 9:52 PM
To: Randy Bush
Cc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'
Subject: Re: [Idr] [v6ops] BGP Identifier

 

Tell me please the large provider t= hat you know has his own automatic configuration tools. I would like to con= tact him to learn from him. 

 

 

From: Randy Bush

Date: 2014-02-18 10:40<= /o:p>

Subject: Re: [Idr] [v6ops] BGP Id= entifier

> Do you have such tools to conf= ig your network? Or do you know the

> vendor that provide such tools= ?Indeed, such programmatic generation

> tools are good for network pla= n. But the logic in the tools is

> complecated especially for a v= ery large network with hierarchical

> operation as Peng Fan mentione= d.

 

there are products in the space, bu= t the large providers i know who

configure programatically developed= their own.  there are not enough

large providers not suffering from = 'not invented here' to make a

reasonable customer base for seriou= s software development.

 

but it pays for itself, so smart fo= lk who develop it.

 

randy

 

--_000_B17A6910EEDD1F45980687268941550F06341989MISOUT7MSGUSR9I_-- From nobody Tue Feb 18 03:36:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3A41A0480; Tue, 18 Feb 2014 03:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew7284S6lqcU; Tue, 18 Feb 2014 03:36:42 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 936E51A060D; Tue, 18 Feb 2014 03:36:40 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee253034538c21-5ac21; Tue, 18 Feb 2014 19:34:16 +0800 (CST) X-RM-TRANSID: 2ee253034538c21-5ac21 Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee253034534311-fc8f6; Tue, 18 Feb 2014 19:34:16 +0800 (CST) X-RM-TRANSID: 2ee253034534311-fc8f6 Date: Tue, 18 Feb 2014 19:36:26 +0800 From: "lizhenqiang@chinamobile.com" To: =?utf-8?B?VVRUQVJPLCBKQU1FUw==?= , "Randy Bush" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , <2014021810513701058825@chinamobile.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <201402181936265926758@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart620801886436_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/Q0EdALqVD0T_jVlstzrnHX10qus Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 11:36:45 -0000 This is a multi-part message in MIME format. ------=_001_NextPart620801886436_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 CgoKCgoKCgoKClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgaW5mb3JtYXRpb24sIEppbS5X ZSBhbHNvIGhhdmUgc29tZSB0b29scyB0byBoZWxwIHVzIHRvIHBsYW4gYW5kIG9wZXJhdGUgb3Vy IG5ldHdvcmtzLiBIb3dldmVyIGF0IHByZXNlbnQgbm9uZSBvZiB0aGUgdG9vbHMgY2FuIHNhdGlz ZnkgdGhlIHJlcXVpcm1lbnQgb2YgdGhpcyBkcmFmdC4KQW55d2F5LCB5b3UgZG8gbm90IHRoaW5r IGl0IGlzIGEgcHJvYmxlbSB0byBwbGFuIHRoZSAzMi1iaXQgQkdQIElEIGZvciBhIHZlcnkgbGFy Z2Ugc2NhbGUgSVB2Ni1vbmx5IG5ldHdvcms/CgoKCmxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNv bQrCoEZyb206wqBVVFRBUk8sIEpBTUVTRGF0ZTrCoDIwMTQtMDItMTjCoDE5OjI3VG86wqBsaXpo ZW5xaWFuZ0BjaGluYW1vYmlsZS5jb207IFJhbmR5IEJ1c2hDQzrCoCdpZHIgd2cnOyAnVjYgT3Bz IExpc3QnOyAnUm9iZXJ0IFJhc3p1aydTdWJqZWN0OsKgUkU6IFtJZHJdIFt2Nm9wc10gQkdQIElk ZW50aWZpZXIKCgoKCgoKCldlIGhhdmUgZGV2ZWxvcGVkIG51bWVyb3VzIGNvbmZpZ3VyYXRpb24g dG9vbHMgdGhhdCBjcmVhdGUvbW9kIFBFLCBSUiBjb25maWdzLiBXZSBhbHNvIGhhdmUgbG90cyBv ZiB0b29scyB0aGF0IHNwZWFrIHRvIHRoZSBuZXR3b3JrIGluIGEgbGl2ZSBzZW5zZSB0byBnZXQg aGVhbHRoLAogc3RhdHMg4oCmIEFsbCBvZiB0aGUgcmF3IG1hdGVyaWFsIGlzIHJlYWRpbHkgYXZh aWxhYmxlLiBUQkggSSBjYW5ub3Qgc3BlYWsgdG8geW91IGFib3V0IG91ciBzb2x1dGlvbnMgaW4g YW55bW9yZSBkZXB0aC4uCsKgCkppbSBVdHRhcm8KwqAKCgpGcm9tOiBJZHIgW21haWx0bzppZHIt Ym91bmNlc0BpZXRmLm9yZ10KT24gQmVoYWxmIE9mIGxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNv bQoKU2VudDogTW9uZGF5LCBGZWJydWFyeSAxNywgMjAxNCA5OjUyIFBNCgpUbzogUmFuZHkgQnVz aAoKQ2M6ICdpZHIgd2cnOyAnVjYgT3BzIExpc3QnOyAnUm9iZXJ0IFJhc3p1aycKClN1YmplY3Q6 IFJlOiBbSWRyXSBbdjZvcHNdIEJHUCBJZGVudGlmaWVyCgoKwqAKClRlbGwgbWUgcGxlYXNlIHRo ZSBsYXJnZSBwcm92aWRlciB0aGF0IHlvdSBrbm93IGhhcyBoaXMgb3duIGF1dG9tYXRpYyBjb25m aWd1cmF0aW9uIHRvb2xzLiBJIHdvdWxkIGxpa2UgdG8gY29udGFjdCBoaW0gdG8gbGVhcm4gZnJv bSBoaW0uwqAKCgrCoAoKCgoKCgoKbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tCgoKCgoKwqAK CgoKCkZyb206wqBSYW5keQogQnVzaAoKCkRhdGU6wqAyMDE0LTAyLTE4wqAxMDo0MAoKClRvOsKg bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tCgoKQ0M6wqBmYW5wZW5nOwonaWRyIHdnJzsgJ1Y2 IE9wcyBMaXN0JzsKJ1JvYmVydCBSYXN6dWsnCgoKU3ViamVjdDrCoFJlOiBbSWRyXSBbdjZvcHNd IEJHUCBJZGVudGlmaWVyCgoKCgoKPiBEbyB5b3UgaGF2ZSBzdWNoIHRvb2xzIHRvIGNvbmZpZyB5 b3VyIG5ldHdvcms/IE9yIGRvIHlvdSBrbm93IHRoZQoKCj4gdmVuZG9yIHRoYXQgcHJvdmlkZSBz dWNoIHRvb2xzP0luZGVlZCwgc3VjaMKgcHJvZ3JhbW1hdGljIGdlbmVyYXRpb24KCgo+IHRvb2xz IGFyZSBnb29kIGZvciBuZXR3b3JrIHBsYW4uIEJ1dCB0aGUgbG9naWMgaW4gdGhlIHRvb2xzIGlz CgoKPiBjb21wbGVjYXRlZCBlc3BlY2lhbGx5IGZvciBhIHZlcnkgbGFyZ2UgbmV0d29yayB3aXRo wqBoaWVyYXJjaGljYWwKCgo+IG9wZXJhdGlvbiBhcyBQZW5nIEZhbiBtZW50aW9uZWQuCgoKwqAK Cgp0aGVyZSBhcmUgcHJvZHVjdHMgaW4gdGhlIHNwYWNlLCBidXQgdGhlIGxhcmdlIHByb3ZpZGVy cyBpIGtub3cgd2hvCgoKY29uZmlndXJlIHByb2dyYW1hdGljYWxseSBkZXZlbG9wZWQgdGhlaXIg b3duLsKgIHRoZXJlIGFyZSBub3QgZW5vdWdoCgoKbGFyZ2UgcHJvdmlkZXJzIG5vdCBzdWZmZXJp bmcgZnJvbSAnbm90IGludmVudGVkIGhlcmUnIHRvIG1ha2UgYQoKCnJlYXNvbmFibGUgY3VzdG9t ZXIgYmFzZSBmb3Igc2VyaW91cyBzb2Z0d2FyZSBkZXZlbG9wbWVudC4KCgrCoAoKCmJ1dCBpdCBw YXlzIGZvciBpdHNlbGYsIHNvIHNtYXJ0IGZvbGsgd2hvIGRldmVsb3AgaXQuCgoKwqAKCgpyYW5k eQoKCsKgCgoKCgoKCgo= ------=_001_NextPart620801886436_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0AThank you very much for your information, Jim.
W= e also have some tools to help us to plan and operate our networks. Howeve= r at present none of the tools can satisfy the requirment of this draft.

Anyway, you do not think it is a problem to plan t= he 32-bit BGP ID for a very large scale IPv6-only network?
=0A
=0A
=0A
lizhenqiang@chinamobile.com
= =0A
 
From: <= a href=3D"mailto:ju1738@att.com" style=3D"color: blue; text-decoration: un= derline;">UTTARO, JAMES
Date: 2014-02-18 19= :27
=0A=0A
=0A

We have developed numerous configuration tools that create/mod P= E, RR configs. We also have lots of tools that speak to the network in a l= ive sense to get health,=0A stats =E2=80=A6 All of the raw material is rea= dily available. TBH I cannot speak to you about our solutions in anymore d= epth..

=0A

 

=0A

Jim Uttaro<= /span>

=0A

 

=0A
=0A
=0A

From: I= dr [mailto:idr-bounces@ietf.org]=0AOn Behalf Of lizhenqiang@chinamo= bile.com
=0ASent: Monday, February 17, 2014 9:52 PM
=0ATo:= Randy Bush
=0ACc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'<= br>=0ASubject: Re: [Idr] [v6ops] BGP Identifier=0A

=0A
=0A

 = ;

=0A
=0A

Tell me please the large provider that you know has his own automat= ic configuration tools. I would like to contact him to learn from him. 

=0A
= =0A
=0A

 

=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A

 

=0A
=0A
=0A
=0A=0A

From:Randy=0A Bush

=0A
=0A
= =0A

Date: 2014-02-18 10:40

=0A
=0A
=0A

To: lizhenqiang@chinamobile.com=0A

=0A=0A
=0A

Su= bject: Re: [Idr] [v6ops] BGP Ident= ifier

=0A
=0A
=0A
=0A
=0A
=0A<= p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; = font-family: 'Times New Roman', serif;">> Do you have= such tools to config your network? Or do you know the=0A
=0A
=0A

> vendor that provide such tools?Indeed, such programmatic = generation

=0A
=0A
=0A

> tools are good for network plan.= But the logic in the tools is

=0A
=0A
=0A> complecated = especially for a very large network with hierarchical

=0A
=0A
=0A

> operation as Peng Fan mentioned.

=0A<= /div>=0A
=0A

 

=0A
=0A
=0A

there are products in the space, but the= large providers i know who

=0A
=0A
=0A

configure programati= cally developed their own.  there are not enough=0A

=0A
=0A

large providers not suffering from 'not invented here' to make a

=0A
=0A
=0A

reasonable customer base for serious software deve= lopment.

=0A
=0A
=0A

 

=0A
= =0A
=0A

but = it pays for itself, so smart folk who develop it.

=0A=
=0A
=0A

randy

=0A
=0A=
=0A

 <= o:p>

=0A
=0A
=0A
=0A
=0A<= /div>=0A ------=_001_NextPart620801886436_=------ From nobody Tue Feb 18 07:23:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F54C1A0324; Mon, 17 Feb 2014 19:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_BIG_TO_CC=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyOi0aeDQ55l; Mon, 17 Feb 2014 19:31:15 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 167E11A02CC; Mon, 17 Feb 2014 19:31:12 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302d371cc7-f3cc7; Tue, 18 Feb 2014 11:28:49 +0800 (CST) X-RM-TRANSID: 2ee15302d371cc7-f3cc7 Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35302d36ef31-dcc4e; Tue, 18 Feb 2014 11:28:49 +0800 (CST) X-RM-TRANSID: 2ee35302d36ef31-dcc4e Date: Tue, 18 Feb 2014 11:30:59 +0800 From: "lizhenqiang@chinamobile.com" To: "Randy Bush" , Farmer , jaeggli , Amante , Morrow , JAMES , Doering , Raszuk' References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <2014021811305909988540@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart655784812418_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/24aw4hhTWyqnrG49Q3QhYUsrXMw X-Mailman-Approved-At: Tue, 18 Feb 2014 07:23:41 -0800 Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 03:31:17 -0000 This is a multi-part message in MIME format. ------=_001_NextPart655784812418_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 CgoKCgoKSGkgQWxsLApUaGFuayB5b3UgYWxsIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzIGFu ZCBpbnRlcmVzdHMgaW4gdGhpcyBkcmFmdC6gQW55IHRlY2huaWNhbCBjb25jZXJucyBhYm91dCB0 aGUgZHJhZnQ/IElzIHRoZXJlIHNvbWVvbmUgaW4gdGhlIG1haWwgbGlzdCBmcm9tIG9wZXJhdG9y cyB0aGF0IGhhcyB0aGUgc2FtZSBwcm9ibGVtIGFzIG1lPwpNYW55IFRoYW5rcyxaaGVucWlhbmcg TGkKCgoKCgoK ------=_001_NextPart655784812418_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi All,

Thank you all for your valuable comments and interests in this dr= aft. 
Any technical concerns about the draft? Is there some= one in the mail list from operators that has the same problem as me?
=

Many Thanks,
Zhenqiang Li
=0A

<= /div>
=0A
=0A

=0A
=0A ------=_001_NextPart655784812418_=------ From nobody Tue Feb 18 07:23:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E0F1A0324; Mon, 17 Feb 2014 19:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_BIG_TO_CC=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hozu1y0uCpOd; Mon, 17 Feb 2014 19:41:59 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8928F1A030F; Mon, 17 Feb 2014 19:41:58 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so11654934lbi.7 for ; Mon, 17 Feb 2014 19:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QnvApghAhd02DHIa5tV4nmdNjz0c9Sy6k5zvfPVVg9o=; b=J1Y43M4WbeXczHq+X8xYKolqbAUVTcOZGUbkg6ow74GyfU9olgQ5Q0RGL1C8AJ5NLm oXoa+bhmTM85JgQ50iQMOaUQteMagvK41IbW1OF3Opd2tAugXv44ITBl3wZ/yweWaVBI kzYswGgfRkDKIXObTw5X7v+8PK1kUIiRb3115uaenI9Rtim55pQPhrpppM6HEa0vBe/A 4R1twDyiXx+sGc2AbnctyLRcdyjKjCGIzvNVAp0B+hZhK609yd0xW74iOrsctHH7mn8Q j2Dfm8gK5HEmgtzGa7ZsfwM1Ki3WIr4Q9jBojcYmY3h5zSC19w3Zke4NO5DYkSd4JswU U8Hg== MIME-Version: 1.0 X-Received: by 10.153.3.2 with SMTP id bs2mr19797812lad.5.1392694914957; Mon, 17 Feb 2014 19:41:54 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.152.203.167 with HTTP; Mon, 17 Feb 2014 19:41:54 -0800 (PST) In-Reply-To: <2014021811305909988540@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> Date: Mon, 17 Feb 2014 22:41:54 -0500 X-Google-Sender-Auth: NwdAWS6xWiKrFAHt_GdJYxxg0vc Message-ID: From: Christopher Morrow To: "lizhenqiang@chinamobile.com" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/d7gT1c9HC9g4rbc6gd_VsKk7VhU X-Mailman-Approved-At: Tue, 18 Feb 2014 07:23:40 -0800 Cc: jaeggli , V6 Ops List , Raszuk' , idr wg , Amante , JAMES , Doering Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 03:42:00 -0000 On Mon, Feb 17, 2014 at 10:30 PM, lizhenqiang@chinamobile.com wrote: > Hi All, > > Thank you all for your valuable comments and interests in this draft. > Any technical concerns about the draft? Is there someone in the mail list > from operators that has the same problem as me? > i think shane's point about 'make a stab at transition technique' still needs to be dealt with, yes? and really... I don't see a huge reason to do this anyway, yet. > Many Thanks, > Zhenqiang Li > > ________________________________ > From nobody Tue Feb 18 07:23:50 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB31E1A033F for ; Mon, 17 Feb 2014 20:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-LATjMeY8jG for ; Mon, 17 Feb 2014 20:12:19 -0800 (PST) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id E62861A0331 for ; Mon, 17 Feb 2014 20:12:18 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id x10so15604518pdj.25 for ; Mon, 17 Feb 2014 20:12:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yqgmQL1h/TgQqpDFEudTHTmxRGOJk109/EUAFzkrvYk=; b=gpqGDeE9ZFZqWU3Kg+TJcooNyz9RB0TWxwnE2jraQN2MRXSgBDJg1D4T+uJIMCb63k mXFJEzQdYIpAGDGTTwcq8f626NeChw71W3I7UkKx51yK3onEu1aw9GvbHAa3A9hRnbeS npl3M55s0JIMMFFwHK5uIiKFDFmG1fYu5MkV1IzwY2juAmcrRBEDqwqAy2xVdknRy3wU CMPBgC0lXBE5kuM59T0dBjZ4XVx1NE6M2BdnIrq8uiRvWaunCh/RT0Fwlw5vClbGN1OH SRL832GDqwoOiMro0MZLfuiStJ4m8Tcf4uUNK16vVYWgnA3+tJ3ZukQ+4nxP0jGuXyWk Nrsg== X-Gm-Message-State: ALoCoQlfK9sdS5joTxQSuwo8Ru/BmQGuSI3eCtUsDkh3nsG+1DIFP5v3SqKeTshh6Vai+MHL+s26 MIME-Version: 1.0 X-Received: by 10.66.176.143 with SMTP id ci15mr30390904pac.35.1392696736231; Mon, 17 Feb 2014 20:12:16 -0800 (PST) Received: by 10.70.88.203 with HTTP; Mon, 17 Feb 2014 20:12:16 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:7c40:c788:ae6f:c53c] In-Reply-To: <5302D994.1030801@bogus.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> <2014021810450694712020@chinamobile.com> <5302D994.1030801@bogus.com> Date: Tue, 18 Feb 2014 14:12:16 +1000 Message-ID: From: George Michaelson To: joel jaeggli Content-Type: multipart/alternative; boundary=047d7bd751603e482e04f2a67a89 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/xjsm_A4he3j3spNmy3veztBHSXA X-Mailman-Approved-At: Tue, 18 Feb 2014 07:23:38 -0800 Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 04:12:21 -0000 --047d7bd751603e482e04f2a67a89 Content-Type: text/plain; charset=ISO-8859-1 240/4 had drafts against it. NEVER is alas, not a normative word in what Joel said. Juniper already includes a flag to use 240/4 in cloud, at the request of a cloud services company. On Tue, Feb 18, 2014 at 1:55 PM, joel jaeggli wrote: > On 2/17/14, 6:45 PM, lizhenqiang@chinamobile.com wrote: > > > > > > > > > > > > > > Thank you very much, Mr. Morrow. Yes, it is a good start. I will > > contact Vijay for detail. However, I do not see the function that we > > want from the slides. In fact, we also use some tools to assist our > > network plan. However, the tools can not satisfy such complex > > requirement. In a hierarchical operation network, the tools to > > implement the logic we want is not a easy job. Zhenqiang Li > > We allocate ipv4 addresses today presumably, which implies the existence > of business logic in basically all isps that accounts for the hierarchic > allocation of 32 bit numbers. > > A brief cruise over to > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml > > Reveals a pool of at least 28 bits (a /4 in ipv4 land) worth of 32bit > numbers that will never overlap with ipv4 unicast address assignments > that you traditionally use for router-ids. embedding those in family iso > addresses if you like seems harmless and you'll never accidentally > configure one as a unicast address on an interface. it'll be a little > while before I need 268 million bgp speaking routers in the same AS. > > > > > > From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr > > wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6ops] BGP > > Identifierhttp:// > www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf > > > > Mike's presentation (given by vijay) is a decent start... > > > > On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush wrote: > >>> Would you please give me an example about how modern large ISPs > >>> manage their networks? > >> > >> programmatic generation of configurations from databases. > >> > >> randy > >> > >> _______________________________________________ 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 > > > > > > > > > > _______________________________________________ v6ops mailing list > > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7bd751603e482e04f2a67a89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
240/4 had drafts against it. NEVER is alas, not a normativ= e word in what Joel said.

Juniper already includes a fla= g to use 240/4 in cloud, at the request of a cloud services company.


On Tue,= Feb 18, 2014 at 1:55 PM, joel jaeggli <joelja@bogus.com> wro= te:
On 2/17/14, 6:45 PM, lizhenqiang@chinamobile.com wro= te:
>
>
>
>
>
>
> Thank you very much, Mr. Morrow. Yes, it is a good start. I will
> contact Vijay for detail. However, I do not see the function that we > want from the slides. In fact, we also use some tools to assist our > network plan. However, the tools can not satisfy such complex
> requirement. In a hierarchical operation network, the tools to
> implement the logic we want is not a easy job. Zhenqiang Li

We allocate ipv4 addresses today presumably, which implies the existe= nce
of business logic in basically all isps that accounts for the hierarchic allocation of 32 bit numbers.

A brief cruise over to

http://www.iana.org/assignments/ipv4-address= -space/ipv4-address-space.xhtml

Reveals a pool of =A0at least 28 bits (a /4 in ipv4 land) worth of 32bit numbers that will never overlap with ipv4 unicast address assignments
that you traditionally use for router-ids. embedding those in family iso addresses if you like seems harmless and you'll never accidentally
configure one as a unicast address on an interface. it'll be a little while before I need 268 million bgp speaking routers in the same AS.


>
> From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr
> wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6op= s] BGP
> Identifierhttp://www.nano= g.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf
>
> =A0Mike's presentation (given by vijay) is a decent start...
>
> On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush <randy@psg.com> wrote:
>>> Would you please give me an example about how modern large ISP= s
>>> manage their networks?
>>
>> programmatic generation of configurations from databases.
>>
>> randy
>>
>> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org= /mailman/listinfo/idr
>
> _______________________________________________ Idr mailing list
> Idr@ietf.org https://www.ietf.org/mai= lman/listinfo/idr
>
>
>
>
> ________________________= _______________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.o= rg/mailman/listinfo/v6ops
>



_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7bd751603e482e04f2a67a89-- From nobody Tue Feb 18 07:23:52 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6628E1A0344; Mon, 17 Feb 2014 21:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0ybUTs4GxHT; Mon, 17 Feb 2014 21:27:46 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A4DF31A0433; Mon, 17 Feb 2014 21:27:42 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25302eeaf544-54544; Tue, 18 Feb 2014 13:25:03 +0800 (CST) X-RM-TRANSID: 2ee25302eeaf544-54544 Received: from X6X8D79D8F49E2 (unknown[10.2.43.104]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35302eeadce4-decf8; Tue, 18 Feb 2014 13:25:03 +0800 (CST) X-RM-TRANSID: 2ee35302eeadce4-decf8 From: "Fan, Peng" To: "'Christopher Morrow'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> In-Reply-To: Date: Tue, 18 Feb 2014 13:28:10 +0800 Message-ID: <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QKQBeNnAdstUIkBXjGXJpkQ3UEQ Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/idr/REIGxLJ41W7-RZLStNWXJ-1-vF4 X-Mailman-Approved-At: Tue, 18 Feb 2014 07:23:41 -0800 Cc: 'jaeggli' , 'V6 Ops List' , 'Raszuk'' , 'idr wg' , 'Amante' , 'JAMES' , 'Doering' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 05:27:48 -0000 Hi Christopher, Normally it is easier to handle routers within the AS as we have full control over it. I think the key point is the ASBR, as we have no control of its eBGP peers. A simple approach is to enable both this extension and RFC6286, and assign a 32-bit ID in addition to the 128-bit one for backup purpose before we are aware of the capability of its peers. The ASBR prefers the 128-bit ID. Since the ID field of OPEN message sent by the ASBR is zero, which will result in a "bad bgp identifier" error message sent by the peer if it does not support the new 128-bit ID capability, the ASBR will know the type of its peer. The ASBR can initiate a second connection in the old way, and the connection falls back using 32-bit ID. Peng > -----Original Message----- > From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] > On Behalf Of Christopher Morrow > Sent: Tuesday, February 18, 2014 11:42 AM > To: lizhenqiang@chinamobile.com > Cc: Randy Bush; Farmer; jaeggli; Amante; JAMES; Doering; Raszuk'; fanpeng; idr > wg; V6 Ops List > Subject: Re: Re: [Idr] [v6ops] BGP Identifier > > On Mon, Feb 17, 2014 at 10:30 PM, lizhenqiang@chinamobile.com > wrote: > > Hi All, > > > > Thank you all for your valuable comments and interests in this draft. > > Any technical concerns about the draft? Is there someone in the mail > > list from operators that has the same problem as me? > > > > i think shane's point about 'make a stab at transition technique' > still needs to be dealt with, yes? > > and really... I don't see a huge reason to do this anyway, yet. > > > Many Thanks, > > Zhenqiang Li > > > > ________________________________ > > From nobody Tue Feb 18 08:06:48 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BD31A069B; Tue, 18 Feb 2014 08:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zfBeFPexa6C; Tue, 18 Feb 2014 08:06:42 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 741FD1A0693; Tue, 18 Feb 2014 08:06:42 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7A02DC25C; Tue, 18 Feb 2014 11:06:39 -0500 (EST) Date: Tue, 18 Feb 2014 11:06:39 -0500 From: Jeffrey Haas To: "Fan, Peng" Message-ID: <20140218160639.GC12348@pfrc> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/v4MhAFRO5yYFysJ7YhKBLabHNVU Cc: 'idr wg' , 'V6 Ops List' , 'Raszuk'' , 'jaeggli' , 'Amante' , 'JAMES' , 'Doering' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:06:47 -0000 On Tue, Feb 18, 2014 at 01:28:10PM +0800, Fan, Peng wrote: > Normally it is easier to handle routers within the AS as we have full > control over it. I think the key point is the ASBR, as we have no control of > its eBGP peers. A simple approach is to enable both this extension and > RFC6286, and assign a 32-bit ID in addition to the 128-bit one for backup > purpose before we are aware of the capability of its peers. I am not in favor of this draft. While I understand the operational desire for it, what the routing protocols (not just BGP) require is just some magic number to be used to identify various protocol properties tied to a given router. I don't think we want to see a series of similar drafts updating every other protocol in an attempt to realize a consistent 128 bit router id throughout an AS. The fact that this number has been able to receive a mapping to a real address has been extremely operationally useful. What I would instead suggest is finding a mechanism by which the unique router-ID can be mapped easily to such addresses. I don't believe that BGP is the right place to do this. -- Jeff From nobody Tue Feb 18 09:16:14 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374C81A06B4; Tue, 18 Feb 2014 09:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCZw-hRfp_Jo; Tue, 18 Feb 2014 09:16:07 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0181A06A6; Tue, 18 Feb 2014 09:16:07 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id s1IHDsC1024246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Feb 2014 12:13:55 -0500 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: Date: Tue, 18 Feb 2014 12:13:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Tue, 18 Feb 2014 12:13:56 -0500 (EST) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/b0KQc8vj1pSI1zNJDaEz2hfQv6A Cc: idr wg , V6 Ops List , Robert Raszuk Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:16:09 -0000 On Feb 17, 2014, at 10:17 PM, Randy Bush wrote: >> Tell me please the large provider that you know has his own automatic >> configuration tools. >=20 > l(3), ntt, ... >=20 >> I would like to contact him to learn from him.=20 >=20 > it is considered secret sauce we (ntt) have presented about this automation in the past. google comes up with a few of these: http://www.nanog.org/meetings/nanog54/presentations/Tuesday/Morris.pdf = http://www.us.ntt.net/news/viewFile.cfm/NTT_Editorial_Capacity_Magazine_no= v_2013.pdf?file_id=3D144 http://ptt.br/pttforum/7/doc/ptt_forum7_morris.pdf - Jared From nobody Tue Feb 18 13:30:07 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBD41A0276 for ; Tue, 18 Feb 2014 13:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNuRrMrlOLqo for ; Tue, 18 Feb 2014 13:30:00 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E30DD1A0081 for ; Tue, 18 Feb 2014 13:29:59 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1ILTq46007000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Feb 2014 15:29:53 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s1ILTpUd027532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 16:29:51 -0500 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.65]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 18 Feb 2014 16:29:51 -0500 From: "Simpson, Adam (Adam)" To: Robert Raszuk , "" , "Saikat Ray (sairay)" Thread-Topic: [Idr] Flowspec, coexistance of redirect and mirror actions Thread-Index: AQHPLPCOSG8zLJhQf0q3nYKPs4k9UQ== Date: Tue, 18 Feb 2014 21:29:51 +0000 Message-ID: References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> <8ED5B0B0F5B4854A912480C1521F973A11B2B080@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A11B2B12C@xmb-rcd-x13.cisco.com> <27431_1392716484_53032AC4_27431_3232_1_EEE55384044474429A926C625D0FCC810C340A35AD@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F309559B9D6A74E876639DAC2C64936@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/lU32UO7O21iN61vbsuP6xBpB5rI Cc: "mtexier@arbor.net" , "idr@ietf.org" , "ju1738@att.com" , Jeff Haas , "David Smith \(djsmith\)" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:30:04 -0000 Just to avoid any further confusion: draft-simpson-idr-flowspec-redirect has been replaced by draft-ietf-idr-flowspec-redirect-ip-00. As Jeff suggested, a new version of draft-ietf-idr-flowspec-redirect-ip will be posted imminently and in the new version the encoding of the IP address that is the redirection target is completely contained within the extended community of the flow-spec action. We agree that overloading the NEXT_HOP field to carry the redirect IP address, as proposed in the 00 draft, was in retrospect not the best choice. With this change there is no technical issue having multiple redirect extended communities in one UPDATE, each pointing to a potentially different target address. -Adam On 2/18/2014, 4:48 AM, "Robert Raszuk" wrote: >It is more then that ... > >The reason Pedro and I originally chosen to go via VRF was precisely >to avoid distributing encapsulation destination(s) as well as >encapsulation types within the flow spec routes leaving it to local >(special) VRF. > >Moreover some PEs may have locally attached inspection devices so it >would be impossible to universally send such redirect destination >action via p2mp protocol. > >If authors of the new draft insist on the embedded redirect/mirror >destination I would highly recommend not to use the "global" next hop >from MP-REACH but to allow space to carry one within the action >instructions. That way one could use different address for different >actions. > >Regards, >R. > > >On Tue, Feb 18, 2014 at 10:41 AM, wrote: >> This may not be a good solution to rely on nexthop field . Something >>similar >> to VRF Redirect may be better (encode redirect IP in the community) and >>may >> permit to use multiple instance of the community. >> >> It's important to keep FIB check to ensure reachability to the encoded >>IP. >> >> >> >> De : Saikat Ray (sairay) [mailto:sairay@cisco.com] >> Envoy=E9 : lundi 17 f=E9vrier 2014 23:03 >> =C0 : Robert Raszuk >> Cc : LITKOWSKI Stephane DTF/DERX; Bertrand Duvivier (bduvivie); Pradosh >> Mohapatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith >> (djsmith); Jeff Haas >> Objet : RE: [Idr] Flowspec, coexistance of redirect and mirror actions >> >> >> >> I was referring to draft-simpson-idr-flowspec-redirect. >> >> >> >> "The filter entry matches the IP packets described in >> >> the NLRI field and redirects them (C=3D0) or copies them (C=3D1) towa= rds >> >> the IPv4 or IPv6 address specified in the 'Network Address of Next- >> >> Hop' field of the associated MP_REACH_NLRI." >> >> >> >> I assumed this thread is for draft-simpson-idr-flowspec-redirect since >>that >> is what the first email in the thread refers to. >> >> >> >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Monday, February 17, 2014 1:46 PM >> To: Saikat Ray (sairay) >> Cc: stephane.litkowski@orange.com; Bertrand Duvivier (bduvivie); Pradosh >> Mohapatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith >> (djsmith); Jeff Haas >> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions >> >> >> >> Saikat, >> >> >> >> Flowspec RFC5575 is not using next hop for it's actions. In fact BGP >> NEXT_HOP is optional. >> >> >> >> A given flow may be associated with a set of attributes, depending on >> >> the particular application; such attributes may or may not include >> >> reachability information (i.e., NEXT_HOP) >> >> >> >> >> >> Instead we use the RT match to determine which local VRF is used for >> redirect or mirror. Stephane's proposal is wise IMO as we could list >> different VRFs one for each required action. The forwarding or >>encapsulation >> itself is defined in those redirect/mirror VRFs. >> >> >> >> >> Redirect: The redirect extended community allows the traffic to >>be >> >> redirected to a VRF routing instance that lists the specified >> >> route-target in its import policy. If several local instances >> >> match this criteria, the choice between them is a local matter >> >> (for example, the instance with the lowest Route Distinguisher >> >> value can be elected). This extended community uses the same >> >> encoding as the Route Target extended community [RFC4360]. >> >> >> >> >> >> Best, >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay) >> wrote: >> >> A given update (a BGP path) has only one NEXTHOP (the NEXTHOP determines >> where to redirect or mirror the packets). >> >> >> >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of >> stephane.litkowski@orange.com >> Sent: Monday, February 17, 2014 1:19 AM >> To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra >> Cc: mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith >>(djsmith); >> Jeff Haas >> >> >> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions >> >> >> >> Hi, >> >> >> >> In order to have both actions applied, why not setting twice time the >> extcommunity in the BGP update ? (one with C=3D0 and one with C=3D1). >> >> Does this cause any issue ? >> >> >> >> Applying multiple actions by setting multiple extcts seems to be >>authorized, >> so why not using the same thing here by setting twice time the same >>extct >> with different C flag. Otherwise need to split it in two different >>extcts. >> >> >> >> Thoughts ? >> >> >> >> >> >> Best Regards, >> >> >> >> Stephane >> >> >> >> >> >> De : Idr [mailto:idr-bounces@ietf.org] De la part de Bertrand Duvivier >> (bduvivie) >> Envoy=E9 : mardi 11 f=E9vrier 2014 21:39 >> =C0 : Robert Raszuk; Pradosh Mohapatra >> Cc : mtexier@arbor.net; idr@ietf.org; ju1738@att.com; Jeff Haas; David >>Smith >> (djsmith) >> Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror actions >> >> >> >> Hi, >> >> >> >> I see 2 cases: >> >> >> >> Signaling primary/backup actions >> >> >> >> We could control path priority using LP or MED. >> >> Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ... >> >> >> >> Of N path RR could select best 2 or 3 or all best path based on >>preferred >> LP (or MED) >> >> BGP Client could select first action, if not possible due to NH not >> available in RIB, then act on second ... etc... >> >> >> >> Signaling multiple parallel actions. >> >> >> >> I don't have answer for this one >> >> >> >> Bertrand >> >> >> >> >> >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >>Robert >> Raszuk >> Sent: mercredi 28 ao=FBt 2013 16:52 >> To: Pradosh Mohapatra >> Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); >> ju1738@att.com >> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions >> >> >> >> Hi Pradosh, >> >> >> >> 5575 still requires you to run BGP best path selection even if you have >> multiple paths. This is both for the onward advertisement as well as >>for the >> local installation. >> >> >> >> You are proposing to install more then "best" path locally which may >> actually require substantial changes to the BGP operation. >> >> >> >> How do you control which paths are to be installed let's say which 2 >>out of >> N ? The multipath checks are not really helpful here. >> >> >> >> It's an interesting question if we in general agree to install multiple >> paths in flowspec SAFI for the exact same NLRI ? >> >> >> >> Regards, >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra >> wrote: >> >> Hi Kaliraj, >> >> >> >> Suggest you use add-path: send two paths for the flow, one with >>next-hop X >> >> and redirect action, the other with next-hop Y and mirror action. >> >> >> >> - Pradosh >> >> >> >> ________________________________ >> >> From: Kaliraj Vairavakkalai >> To: "Simpson, Adam (Adam)" ; >> "ju1738@att.com" ; "pmohapat@cisco.com" >> ; "djsmith@cisco.com" ; >>"Henderickx, >> Wim (Wim)" ; "mtexier@arbor.net" >> >> Cc: Jeff Haas ; "idr@ietf.org" >> Sent: Tuesday, August 27, 2013 10:55 AM >> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions >> >> >> Yes Adam, the original flow with destination A is steered/moved to new >> destination B (e.g. scrubber device) while simultaneously copy of this >>flow >> sent to a new destination C (e.g. for LI) >> >> The devices doing the scrubbing and LI may be different (based on >>devices' >> capability, load-balancing requirement etc), was the thought behind my >> question. >> >> Thanks, >> Kaliraj >>> -----Original Message----- >>> From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] >>> Sent: Tuesday, August 27, 2013 10:19 AM >>> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com; >>> djsmith@cisco.com; Henderickx, Wim (Wim); mtexier@arbor.net >>> Cc: Jeff Haas; idr@ietf.org >>> Subject: Re: Flowspec, coexistance of redirect and mirror actions >>> >>> Hi Kaliraj, >>> >>> You are correct; these actions are mutually exclusive according to the >>> current >>> encoding. What does it mean for you to have a flow both moved >>> (redirected) and copied (mirrored)? Do you mean the original flow with >>> destination A is steered/moved to new destination B while at the same >>>time >>> a >>> copy of this flow is sent to a new destination C? I personally have not >>> seen a >>> requirement for this type of compound action but I will leave the other >>> authors to comment as well. >>> >>> -Adam >>> >>> >>> On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" >>> wrote: >>> >>> >Hi authors, >>> > >>> >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 >>> > >>> >If it is desired to perform both "redirect-action" to a nexthop X, and >>> >"mirror-action" to a different nexthop Y simultaneously for the same >>> >flow, how is it achieved? >>> > >>> >It appears the signaling for such a scenario may not be handled by the >>> >mechanisms specified in this draft, unless I am missing something. >>> >Could you pls clarify. >>> > >>> >Thanks >>> >Kaliraj >>> > >>> >>> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> >>=20 >>_________________________________________________________________________ >>________________________________________________ >> >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>recu >> ce message par erreur, veuillez le signaler >> >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> >> Orange decline toute responsabilite si ce message a ete altere, deforme >>ou >> falsifie. Merci. >> >> >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> >> they should not be distributed, used or copied without authorisation. >> >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> >> As emails may be altered, Orange is not liable for messages that have >>been >> modified, changed or falsified. >> >> Thank you. >> >> >> >>=20 >>_________________________________________________________________________ >>________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >>ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >>been >> modified, changed or falsified. >> Thank you. > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From nobody Tue Feb 18 13:31:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9E51A034B for ; Tue, 18 Feb 2014 13:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gj1U_n6zb51 for ; Tue, 18 Feb 2014 13:31:49 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id D76AC1A025A for ; Tue, 18 Feb 2014 13:31:48 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so12844749lbv.10 for ; Tue, 18 Feb 2014 13:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=qyovk6F+PAyf23Lhg8DEWpUyCdCyEQKU7LigrqxLO90=; b=xvGg1wk4sCW9YSCF57H8ThoNRGz6ecrqZ0t4u9yJvb/Skh6ISDxrTZWYlrA6P6B6Wg C1A1McRBGta12nYtMyKXiHvpObWKYVFjdFPqQucj8MQNl14vgeIjajaKAtzo2FuI3KFK HEbP+EYTh5G5SjXBXKrWUo6CK7Jk/0JsSsE1qOKzdRjbwn000DLU2d4FYBZDz2eI46I5 SKbRQfkDjQu3sFVzN4KdqR4juS3N1FRHXB+DFyVjNwnNGt4rIf6HVRp+YYE94AxbwZxR Jz+lTH+DqS5RZ3Wj4FI+yON4yQm5fM+9JUkCVgea3iCGgMftSVpnb2JZfoSPW0Nt9H77 3neA== MIME-Version: 1.0 X-Received: by 10.152.120.201 with SMTP id le9mr208597lab.68.1392759105026; Tue, 18 Feb 2014 13:31:45 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.51.105 with HTTP; Tue, 18 Feb 2014 13:31:44 -0800 (PST) In-Reply-To: References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> <8ED5B0B0F5B4854A912480C1521F973A11B2B080@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A11B2B12C@xmb-rcd-x13.cisco.com> <27431_1392716484_53032AC4_27431_3232_1_EEE55384044474429A926C625D0FCC810C340A35AD@PUEXCB2F.nanterre.francetelecom.fr> Date: Tue, 18 Feb 2014 22:31:44 +0100 X-Google-Sender-Auth: AzJR6-xX41emLzCIbndSBgfAlSg Message-ID: From: Robert Raszuk To: "Simpson, Adam (Adam)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/idr/saXv9BjdMLbAOmmxzyQWQjVXW7w Cc: "mtexier@arbor.net" , "idr@ietf.org" , Jeff Haas , "David Smith \(djsmith\)" , "ju1738@att.com" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:31:52 -0000 Thx Adam for this summary. Very helpful ! Also glad to see the proper encoding shift. Best, R. On Tue, Feb 18, 2014 at 10:29 PM, Simpson, Adam (Adam) wrote: > Just to avoid any further confusion: > > draft-simpson-idr-flowspec-redirect has been replaced by > draft-ietf-idr-flowspec-redirect-ip-00. > > As Jeff suggested, a new version of draft-ietf-idr-flowspec-redirect-ip > will be posted imminently and in the new version the encoding of the IP > address that is the redirection target is completely contained within the > extended community of the flow-spec action. We agree that overloading the > NEXT_HOP field to carry the redirect IP address, as proposed in the 00 > draft, was in retrospect not the best choice. With this change there is n= o > technical issue having multiple redirect extended communities in one > UPDATE, each pointing to a potentially different target address. > > -Adam > > > On 2/18/2014, 4:48 AM, "Robert Raszuk" wrote: > >>It is more then that ... >> >>The reason Pedro and I originally chosen to go via VRF was precisely >>to avoid distributing encapsulation destination(s) as well as >>encapsulation types within the flow spec routes leaving it to local >>(special) VRF. >> >>Moreover some PEs may have locally attached inspection devices so it >>would be impossible to universally send such redirect destination >>action via p2mp protocol. >> >>If authors of the new draft insist on the embedded redirect/mirror >>destination I would highly recommend not to use the "global" next hop >>from MP-REACH but to allow space to carry one within the action >>instructions. That way one could use different address for different >>actions. >> >>Regards, >>R. >> >> >>On Tue, Feb 18, 2014 at 10:41 AM, wrote: >>> This may not be a good solution to rely on nexthop field . Something >>>similar >>> to VRF Redirect may be better (encode redirect IP in the community) and >>>may >>> permit to use multiple instance of the community. >>> >>> It's important to keep FIB check to ensure reachability to the encoded >>>IP. >>> >>> >>> >>> De : Saikat Ray (sairay) [mailto:sairay@cisco.com] >>> Envoy=E9 : lundi 17 f=E9vrier 2014 23:03 >>> =C0 : Robert Raszuk >>> Cc : LITKOWSKI Stephane DTF/DERX; Bertrand Duvivier (bduvivie); Pradosh >>> Mohapatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith >>> (djsmith); Jeff Haas >>> Objet : RE: [Idr] Flowspec, coexistance of redirect and mirror actions >>> >>> >>> >>> I was referring to draft-simpson-idr-flowspec-redirect. >>> >>> >>> >>> "The filter entry matches the IP packets described in >>> >>> the NLRI field and redirects them (C=3D0) or copies them (C=3D1) tow= ards >>> >>> the IPv4 or IPv6 address specified in the 'Network Address of Next- >>> >>> Hop' field of the associated MP_REACH_NLRI." >>> >>> >>> >>> I assumed this thread is for draft-simpson-idr-flowspec-redirect since >>>that >>> is what the first email in the thread refers to. >>> >>> >>> >>> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >>> Raszuk >>> Sent: Monday, February 17, 2014 1:46 PM >>> To: Saikat Ray (sairay) >>> Cc: stephane.litkowski@orange.com; Bertrand Duvivier (bduvivie); Prados= h >>> Mohapatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith >>> (djsmith); Jeff Haas >>> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions >>> >>> >>> >>> Saikat, >>> >>> >>> >>> Flowspec RFC5575 is not using next hop for it's actions. In fact BGP >>> NEXT_HOP is optional. >>> >>> >>> >>> A given flow may be associated with a set of attributes, depending o= n >>> >>> the particular application; such attributes may or may not include >>> >>> reachability information (i.e., NEXT_HOP) >>> >>> >>> >>> >>> >>> Instead we use the RT match to determine which local VRF is used for >>> redirect or mirror. Stephane's proposal is wise IMO as we could list >>> different VRFs one for each required action. The forwarding or >>>encapsulation >>> itself is defined in those redirect/mirror VRFs. >>> >>> >>> >>> >>> Redirect: The redirect extended community allows the traffic to >>>be >>> >>> redirected to a VRF routing instance that lists the specified >>> >>> route-target in its import policy. If several local instances >>> >>> match this criteria, the choice between them is a local matter >>> >>> (for example, the instance with the lowest Route Distinguisher >>> >>> value can be elected). This extended community uses the same >>> >>> encoding as the Route Target extended community [RFC4360]. >>> >>> >>> >>> >>> >>> Best, >>> >>> R. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay) >>> wrote: >>> >>> A given update (a BGP path) has only one NEXTHOP (the NEXTHOP determine= s >>> where to redirect or mirror the packets). >>> >>> >>> >>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of >>> stephane.litkowski@orange.com >>> Sent: Monday, February 17, 2014 1:19 AM >>> To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra >>> Cc: mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith >>>(djsmith); >>> Jeff Haas >>> >>> >>> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions >>> >>> >>> >>> Hi, >>> >>> >>> >>> In order to have both actions applied, why not setting twice time the >>> extcommunity in the BGP update ? (one with C=3D0 and one with C=3D1). >>> >>> Does this cause any issue ? >>> >>> >>> >>> Applying multiple actions by setting multiple extcts seems to be >>>authorized, >>> so why not using the same thing here by setting twice time the same >>>extct >>> with different C flag. Otherwise need to split it in two different >>>extcts. >>> >>> >>> >>> Thoughts ? >>> >>> >>> >>> >>> >>> Best Regards, >>> >>> >>> >>> Stephane >>> >>> >>> >>> >>> >>> De : Idr [mailto:idr-bounces@ietf.org] De la part de Bertrand Duvivier >>> (bduvivie) >>> Envoy=E9 : mardi 11 f=E9vrier 2014 21:39 >>> =C0 : Robert Raszuk; Pradosh Mohapatra >>> Cc : mtexier@arbor.net; idr@ietf.org; ju1738@att.com; Jeff Haas; David >>>Smith >>> (djsmith) >>> Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror actions >>> >>> >>> >>> Hi, >>> >>> >>> >>> I see 2 cases: >>> >>> >>> >>> Signaling primary/backup actions >>> >>> >>> >>> We could control path priority using LP or MED. >>> >>> Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ... >>> >>> >>> >>> Of N path RR could select best 2 or 3 or all best path based on >>>preferred >>> LP (or MED) >>> >>> BGP Client could select first action, if not possible due to NH not >>> available in RIB, then act on second ... etc... >>> >>> >>> >>> Signaling multiple parallel actions. >>> >>> >>> >>> I don't have answer for this one >>> >>> >>> >>> Bertrand >>> >>> >>> >>> >>> >>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >>>Robert >>> Raszuk >>> Sent: mercredi 28 ao=FBt 2013 16:52 >>> To: Pradosh Mohapatra >>> Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); >>> ju1738@att.com >>> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions >>> >>> >>> >>> Hi Pradosh, >>> >>> >>> >>> 5575 still requires you to run BGP best path selection even if you have >>> multiple paths. This is both for the onward advertisement as well as >>>for the >>> local installation. >>> >>> >>> >>> You are proposing to install more then "best" path locally which may >>> actually require substantial changes to the BGP operation. >>> >>> >>> >>> How do you control which paths are to be installed let's say which 2 >>>out of >>> N ? The multipath checks are not really helpful here. >>> >>> >>> >>> It's an interesting question if we in general agree to install multiple >>> paths in flowspec SAFI for the exact same NLRI ? >>> >>> >>> >>> Regards, >>> >>> R. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra >>> wrote: >>> >>> Hi Kaliraj, >>> >>> >>> >>> Suggest you use add-path: send two paths for the flow, one with >>>next-hop X >>> >>> and redirect action, the other with next-hop Y and mirror action. >>> >>> >>> >>> - Pradosh >>> >>> >>> >>> ________________________________ >>> >>> From: Kaliraj Vairavakkalai >>> To: "Simpson, Adam (Adam)" ; >>> "ju1738@att.com" ; "pmohapat@cisco.com" >>> ; "djsmith@cisco.com" ; >>>"Henderickx, >>> Wim (Wim)" ; "mtexier@arbor.net" >>> >>> Cc: Jeff Haas ; "idr@ietf.org" >>> Sent: Tuesday, August 27, 2013 10:55 AM >>> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions >>> >>> >>> Yes Adam, the original flow with destination A is steered/moved to new >>> destination B (e.g. scrubber device) while simultaneously copy of this >>>flow >>> sent to a new destination C (e.g. for LI) >>> >>> The devices doing the scrubbing and LI may be different (based on >>>devices' >>> capability, load-balancing requirement etc), was the thought behind my >>> question. >>> >>> Thanks, >>> Kaliraj >>>> -----Original Message----- >>>> From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] >>>> Sent: Tuesday, August 27, 2013 10:19 AM >>>> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com; >>>> djsmith@cisco.com; Henderickx, Wim (Wim); mtexier@arbor.net >>>> Cc: Jeff Haas; idr@ietf.org >>>> Subject: Re: Flowspec, coexistance of redirect and mirror actions >>>> >>>> Hi Kaliraj, >>>> >>>> You are correct; these actions are mutually exclusive according to the >>>> current >>>> encoding. What does it mean for you to have a flow both moved >>>> (redirected) and copied (mirrored)? Do you mean the original flow with >>>> destination A is steered/moved to new destination B while at the same >>>>time >>>> a >>>> copy of this flow is sent to a new destination C? I personally have no= t >>>> seen a >>>> requirement for this type of compound action but I will leave the othe= r >>>> authors to comment as well. >>>> >>>> -Adam >>>> >>>> >>>> On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" >>>> wrote: >>>> >>>> >Hi authors, >>>> > >>>> >Ref: http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-0= 2 >>>> > >>>> >If it is desired to perform both "redirect-action" to a nexthop X, an= d >>>> >"mirror-action" to a different nexthop Y simultaneously for the same >>>> >flow, how is it achieved? >>>> > >>>> >It appears the signaling for such a scenario may not be handled by th= e >>>> >mechanisms specified in this draft, unless I am missing something. >>>> >Could you pls clarify. >>>> > >>>> >Thanks >>>> >Kaliraj >>>> > >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>>________________________________________________________________________= _ >>>________________________________________________ >>> >>> >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>recu >>> ce message par erreur, veuillez le signaler >>> >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s >>> electroniques etant susceptibles d'alteration, >>> >>> Orange decline toute responsabilite si ce message a ete altere, deforme >>>ou >>> falsifie. Merci. >>> >>> >>> >>> This message and its attachments may contain confidential or privileged >>> information that may be protected by law; >>> >>> they should not be distributed, used or copied without authorisation. >>> >>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>> >>> As emails may be altered, Orange is not liable for messages that have >>>been >>> modified, changed or falsified. >>> >>> Thank you. >>> >>> >>> >>> >>>________________________________________________________________________= _ >>>________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>recu >>> ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s >>> electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme >>>ou >>> falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >>> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have >>>been >>> modified, changed or falsified. >>> Thank you. >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Feb 18 18:20:06 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE541A042B; Tue, 18 Feb 2014 18:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyOx0bk2gCj0; Tue, 18 Feb 2014 18:20:01 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id CA69C1A031B; Tue, 18 Feb 2014 18:19:59 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2530414436af-686af; Wed, 19 Feb 2014 10:17:40 +0800 (CST) X-RM-TRANSID: 2ee2530414436af-686af Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee353041443628-f44cb; Wed, 19 Feb 2014 10:17:40 +0800 (CST) X-RM-TRANSID: 2ee353041443628-f44cb Date: Wed, 19 Feb 2014 10:19:51 +0800 From: "lizhenqiang@chinamobile.com" To: "Jared Mauch" , "Randy Bush" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <201402191019510556831@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart373522705558_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/AIOljeCjuIzg1_Eb3Rid-eCjjV4 Cc: 'idr wg' , 'V6 Ops List' , 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 02:20:03 -0000 This is a multi-part message in MIME format. ------=_001_NextPart373522705558_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 CgoKCgoKVGhhbmsgeW91IHZlcnkgbXVjaCwgSmFyZWQuIEkgd2lsbCBzdHVkeSBhbGwgdGhlIG1h dGVyaWFsLgoKWmhlbnFpYW5nIExpCgpsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20KoEZyb206 oEphcmVkIE1hdWNoRGF0ZTqgMjAxNC0wMi0xOaAwMToxM1RvOqBSYW5keSBCdXNoQ0M6oGxpemhl bnFpYW5nQGNoaW5hbW9iaWxlLmNvbTsgaWRyIHdnOyBWNiBPcHMgTGlzdDsgUm9iZXJ0IFJhc3p1 a1N1YmplY3Q6oFJlOiBbSWRyXSBbdjZvcHNdIEJHUCBJZGVudGlmaWVyoApPbiBGZWIgMTcsIDIw MTQsIGF0IDEwOjE3IFBNLCBSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPiB3cm90ZToKoAo+PiBU ZWxsIG1lIHBsZWFzZSB0aGUgbGFyZ2UgcHJvdmlkZXIgdGhhdCB5b3Uga25vdyBoYXMgaGlzIG93 biBhdXRvbWF0aWMKPj4gY29uZmlndXJhdGlvbiB0b29scy4KPiAKPiBsKDMpLCBudHQsIC4uLgo+ IAo+PiBJIHdvdWxkIGxpa2UgdG8gY29udGFjdCBoaW0gdG8gbGVhcm4gZnJvbSBoaW0uIAo+IAo+ IGl0IGlzIGNvbnNpZGVyZWQgc2VjcmV0IHNhdWNlCqAKd2UgKG50dCkgaGF2ZSBwcmVzZW50ZWQg YWJvdXQgdGhpcyBhdXRvbWF0aW9uIGluIHRoZSBwYXN0LgqgCmdvb2dsZSBjb21lcyB1cCB3aXRo IGEgZmV3IG9mIHRoZXNlOgqgCmh0dHA6Ly93d3cubmFub2cub3JnL21lZXRpbmdzL25hbm9nNTQv cHJlc2VudGF0aW9ucy9UdWVzZGF5L01vcnJpcy5wZGYKaHR0cDovL3d3dy51cy5udHQubmV0L25l d3Mvdmlld0ZpbGUuY2ZtL05UVF9FZGl0b3JpYWxfQ2FwYWNpdHlfTWFnYXppbmVfbm92XzIwMTMu cGRmP2ZpbGVfaWQ9MTQ0Cmh0dHA6Ly9wdHQuYnIvcHR0Zm9ydW0vNy9kb2MvcHR0X2ZvcnVtN19t b3JyaXMucGRmCqAKLSBKYXJlZAqgCqAKCg== ------=_001_NextPart373522705558_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Thank you very much, Jar= ed. I will study all the material.
=0A

Zhenqiang L= i
=0A
=0A
lizhenqiang@chinamobile.com
=0A=
 
Date: 2014-02-19 01:13
<= b>Subject: Re: [Idr] [v6ops] BGP Identifier
 
=0A
On Feb 17, 2014, at 10:17 PM, Randy Bush <ran= dy@psg.com> wrote:
=0A
 
=0A
>> Tell me pl= ease the large provider that you know has his own automatic
=0A
&= gt;> configuration tools.
=0A
>
=0A
> l(3), nt= t, ...
=0A
>
=0A
>> I would like to contact hi= m to learn from him.
=0A
>
=0A
> it is considere= d secret sauce
=0A
 
=0A
we (ntt) have presented ab= out this automation in the past.
=0A
 
=0A
google c= omes up with a few of these:
=0A
 
=0A
http://www.n= anog.org/meetings/nanog54/presentations/Tuesday/Morris.pdf
=0A
ht= tp://www.us.ntt.net/news/viewFile.cfm/NTT_Editorial_Capacity_Magazine_nov_= 2013.pdf?file_id=3D144
=0A
http://ptt.br/pttforum/7/doc/ptt_forum= 7_morris.pdf
=0A
 
=0A
- Jared
=0A
 <= /div>=0A
 
=0A
=0A ------=_001_NextPart373522705558_=------ From nobody Wed Feb 19 10:41:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A8A1A015E for ; Wed, 19 Feb 2014 10:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU76ImcsnpMa for ; Wed, 19 Feb 2014 10:41:38 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 336F61A00FB for ; Wed, 19 Feb 2014 10:41:38 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 0A442300077 for ; Wed, 19 Feb 2014 18:41:35 +0000 (UTC) Received: from shanes-mbp-5.ciena.com (unknown [205.150.9.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id CC4FF300052; Wed, 19 Feb 2014 11:41:29 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: <20140218160639.GC12348@pfrc> Date: Wed, 19 Feb 2014 10:41:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7E7D0DA0-0CC0-465C-8BA1-81809B1FEF80@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Feb 19 11:41:34 2014 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 5304fade42078343715264 X-DSPAM-Factors: 27, Mime-Version*OS+X, 0.01000, Mime-Version*X+#+#+1827, 0.01000, Cc*List+#+ietf.org, 0.01000, From*Amante+shane, 0.01000, Cc*List+v6ops, 0.01000, Cc*idr+wg, 0.01000, Subject*v6ops+BGP, 0.01000, Cc*Ops+#+v6ops, 0.01000, Mime-Version*OS+#+#+7.1, 0.01000, Cc*idr+ietf.org, 0.01000, Mime-Version*Mac+#+#+#+7.1, 0.01000, Cc*wg+#+ietf.org, 0.01000, Cc*V6+#+#+#+ietf.org, 0.01000, On+#+#+2014, 0.01000, Cc*Ops+List, 0.01000, Subject*BGP+Identifier, 0.01000, Cc*idr+#+#+ietf.org, 0.01000, Cc*V6+#+#+v6ops, 0.01000, Mime-Version*7.1+1827, 0.01000, Cc*V6+Ops, 0.01000, Mime-Version*1.0+Mac, 0.01000, From*Shane+#+shane, 0.01000, Cc*Ops+#+#+ietf.org, 0.01000, Cc*idr+#+idr, 0.01000, From*Shane Amante , 0.01000, is+#+a, 0.01000, 2014+#+#+#+AM, 0.01000 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/iHjECB1w_51x_Ce-RpaWLKcKX34 Cc: idr wg , V6 Ops List , Raszuk , jaeggli , JAMES , Doering Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:41:40 -0000 On Feb 18, 2014, at 8:06 AM, Jeffrey Haas wrote: > The fact that this number has been able to receive a mapping to a real > address has been extremely operationally useful. >=20 > What I would instead suggest is finding a mechanism by which the = unique > router-ID can be mapped easily to such addresses. I don't believe = that BGP is > the right place to do this. +1 -shane From nobody Wed Feb 19 18:36:01 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04951A0638; Wed, 19 Feb 2014 18:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-WfykqtgEZL; Wed, 19 Feb 2014 18:35:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7881A0636; Wed, 19 Feb 2014 18:35:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WGJUN-00026h-Uy; Thu, 20 Feb 2014 02:35:53 +0000 Date: Thu, 20 Feb 2014 10:35:45 +0800 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20140218160639.GC12348@pfrc> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/idr/RPtgpI05XX_4cC_zPQjDM4VIiX4 Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:36:00 -0000 > What I would instead suggest is finding a mechanism by which the > unique router-ID can be mapped easily to such addresses. I don't > believe that BGP is the right place to do this. we need a name to address mapping mechanism. let's all think about that. randy From nobody Thu Feb 20 01:37:33 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB431A0064 for ; Thu, 20 Feb 2014 01:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-9MHlSptWT5 for ; Thu, 20 Feb 2014 01:37:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3E61A003D for ; Thu, 20 Feb 2014 01:37:27 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 1644C2AC409; Thu, 20 Feb 2014 10:37:23 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id E626FC807D; Thu, 20 Feb 2014 10:37:22 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.44]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 20 Feb 2014 10:37:21 +0100 From: To: "Simpson, Adam (Adam)" , Robert Raszuk , "Saikat Ray (sairay)" Date: Thu, 20 Feb 2014 10:37:19 +0100 Thread-Topic: [Idr] Flowspec, coexistance of redirect and mirror actions Thread-Index: AQHPLPCOSG8zLJhQf0q3nYKPs4k9UZq95K3Q Message-ID: <10888_1392889043_5305CCD2_10888_15240_1_EEE55384044474429A926C625D0FCC810C340A3DF5@PUEXCB2F.nanterre.francetelecom.fr> References: <1f2e4342dc3c4f15ace416939ed06a02@BLUPR05MB040.namprd05.prod.outlook.com> <6fda04eda11d46d5ab7885f25131a0f7@BN1PR05MB041.namprd05.prod.outlook.com> <1377639445.8844.YahooMailNeo@web164906.mail.bf1.yahoo.com> <5F1FD493E541C642ABBC18EDC327C82F1F4732E7@xmb-aln-x11.cisco.com> <28766_1392628750_5301D40E_28766_11519_1_EEE55384044474429A926C625D0FCC810C340A30CC@PUEXCB2F.nanterre.francetelecom.fr> <8ED5B0B0F5B4854A912480C1521F973A11B2B080@xmb-rcd-x13.cisco.com> <8ED5B0B0F5B4854A912480C1521F973A11B2B12C@xmb-rcd-x13.cisco.com> <27431_1392716484_53032AC4_27431_3232_1_EEE55384044474429A926C625D0FCC810C340A35AD@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.20.80916 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/qPPjvItjUpGXcf_nfgbvoIdavKc Cc: "mtexier@arbor.net" , "idr@ietf.org" , "ju1738@att.com" , Jeff Haas , "David Smith \(djsmith\)" Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror actions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 09:37:30 -0000 Great improvment ! Thanks -----Message d'origine----- De=A0: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com]=20 Envoy=E9=A0: mardi 18 f=E9vrier 2014 22:30 =C0=A0: Robert Raszuk; LITKOWSKI Stephane DTF/DERX; Saikat Ray (sairay) Cc=A0: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith (djsmith); j= u1738@att.com Objet=A0: Re: [Idr] Flowspec, coexistance of redirect and mirror actions Just to avoid any further confusion: draft-simpson-idr-flowspec-redirect has been replaced by draft-ietf-idr-flo= wspec-redirect-ip-00. As Jeff suggested, a new version of draft-ietf-idr-flowspec-redirect-ip will be posted imminently and in the new version the encoding of the IP add= ress that is the redirection target is completely contained within the exte= nded community of the flow-spec action. We agree that overloading the NEXT_= HOP field to carry the redirect IP address, as proposed in the 00 draft, wa= s in retrospect not the best choice. With this change there is no technical= issue having multiple redirect extended communities in one UPDATE, each po= inting to a potentially different target address. -Adam On 2/18/2014, 4:48 AM, "Robert Raszuk" wrote: >It is more then that ... > >The reason Pedro and I originally chosen to go via VRF was precisely to=20 >avoid distributing encapsulation destination(s) as well as=20 >encapsulation types within the flow spec routes leaving it to local >(special) VRF. > >Moreover some PEs may have locally attached inspection devices so it=20 >would be impossible to universally send such redirect destination=20 >action via p2mp protocol. > >If authors of the new draft insist on the embedded redirect/mirror=20 >destination I would highly recommend not to use the "global" next hop=20 >from MP-REACH but to allow space to carry one within the action=20 >instructions. That way one could use different address for different=20 >actions. > >Regards, >R. > > >On Tue, Feb 18, 2014 at 10:41 AM, wrote: >> This may not be a good solution to rely on nexthop field . Something=20 >>similar to VRF Redirect may be better (encode redirect IP in the=20 >>community) and may permit to use multiple instance of the community. >> >> It's important to keep FIB check to ensure reachability to the=20 >>encoded IP. >> >> >> >> De : Saikat Ray (sairay) [mailto:sairay@cisco.com] Envoy=E9 : lundi 17= =20 >> f=E9vrier 2014 23:03 =C0 : Robert Raszuk Cc : LITKOWSKI Stephane=20 >> DTF/DERX; Bertrand Duvivier (bduvivie); Pradosh Mohapatra;=20 >> mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith=20 >> (djsmith); Jeff Haas Objet : RE: [Idr] Flowspec, coexistance of=20 >> redirect and mirror actions >> >> >> >> I was referring to draft-simpson-idr-flowspec-redirect. >> >> >> >> "The filter entry matches the IP packets described in >> >> the NLRI field and redirects them (C=3D0) or copies them (C=3D1)=20 >> towards >> >> the IPv4 or IPv6 address specified in the 'Network Address of=20 >> Next- >> >> Hop' field of the associated MP_REACH_NLRI." >> >> >> >> I assumed this thread is for draft-simpson-idr-flowspec-redirect=20 >>since that is what the first email in the thread refers to. >> >> >> >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of=20 >> Robert Raszuk >> Sent: Monday, February 17, 2014 1:46 PM >> To: Saikat Ray (sairay) >> Cc: stephane.litkowski@orange.com; Bertrand Duvivier (bduvivie);=20 >> Pradosh Mohapatra; mtexier@arbor.net; idr@ietf.org; ju1738@att.com;=20 >> David Smith (djsmith); Jeff Haas >> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror=20 >> actions >> >> >> >> Saikat, >> >> >> >> Flowspec RFC5575 is not using next hop for it's actions. In fact BGP=20 >> NEXT_HOP is optional. >> >> >> >> A given flow may be associated with a set of attributes, depending=20 >> on >> >> the particular application; such attributes may or may not include >> >> reachability information (i.e., NEXT_HOP) >> >> >> >> >> >> Instead we use the RT match to determine which local VRF is used for=20= =20 >>redirect or mirror. Stephane's proposal is wise IMO as we could list=20= =20 >>different VRFs one for each required action. The forwarding or=20 >>encapsulation itself is defined in those redirect/mirror VRFs. >> >> >> >> >> Redirect: The redirect extended community allows the traffic=20 >>to be >> >> redirected to a VRF routing instance that lists the specified >> >> route-target in its import policy. If several local instances >> >> match this criteria, the choice between them is a local matter >> >> (for example, the instance with the lowest Route Distinguisher >> >> value can be elected). This extended community uses the same >> >> encoding as the Route Target extended community [RFC4360]. >> >> >> >> >> >> Best, >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Feb 17, 2014 at 10:33 PM, Saikat Ray (sairay)=20 >> >> wrote: >> >> A given update (a BGP path) has only one NEXTHOP (the NEXTHOP=20 >> determines where to redirect or mirror the packets). >> >> >> >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of=20=20 >>stephane.litkowski@orange.com >> Sent: Monday, February 17, 2014 1:19 AM >> To: Bertrand Duvivier (bduvivie); Robert Raszuk; Pradosh Mohapatra >> Cc: mtexier@arbor.net; idr@ietf.org; ju1738@att.com; David Smith=20 >>(djsmith); Jeff Haas >> >> >> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror=20 >> actions >> >> >> >> Hi, >> >> >> >> In order to have both actions applied, why not setting twice time the=20 >> extcommunity in the BGP update ? (one with C=3D0 and one with C=3D1). >> >> Does this cause any issue ? >> >> >> >> Applying multiple actions by setting multiple extcts seems to be=20 >>authorized, so why not using the same thing here by setting twice=20 >>time the same extct with different C flag. Otherwise need to split it=20 >>in two different extcts. >> >> >> >> Thoughts ? >> >> >> >> >> >> Best Regards, >> >> >> >> Stephane >> >> >> >> >> >> De : Idr [mailto:idr-bounces@ietf.org] De la part de Bertrand=20 >>Duvivier >> (bduvivie) >> Envoy=E9 : mardi 11 f=E9vrier 2014 21:39 >> =C0 : Robert Raszuk; Pradosh Mohapatra >> Cc : mtexier@arbor.net; idr@ietf.org; ju1738@att.com; Jeff Haas;=20 >>David Smith >> (djsmith) >> Objet : Re: [Idr] Flowspec, coexistance of redirect and mirror=20 >>actions >> >> >> >> Hi, >> >> >> >> I see 2 cases: >> >> >> >> Signaling primary/backup actions >> >> >> >> We could control path priority using LP or MED. >> >> Assuming NLRI x PATH 1 ACTION 1 LP 1, NLRI x PATH 2 ACTION 2 LP2, ... >> >> >> >> Of N path RR could select best 2 or 3 or all best path based on=20 >>preferred LP (or MED) >> >> BGP Client could select first action, if not possible due to NH not=20 >> available in RIB, then act on second ... etc... >> >> >> >> Signaling multiple parallel actions. >> >> >> >> I don't have answer for this one >> >> >> >> Bertrand >> >> >> >> >> >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of=20 >>Robert Raszuk >> Sent: mercredi 28 ao=FBt 2013 16:52 >> To: Pradosh Mohapatra >> Cc: mtexier@arbor.net; idr@ietf.org; Jeff Haas; David Smith=20 >>(djsmith); ju1738@att.com >> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror=20 >>actions >> >> >> >> Hi Pradosh, >> >> >> >> 5575 still requires you to run BGP best path selection even if you=20 >>have multiple paths. This is both for the onward advertisement as=20 >>well as for the local installation. >> >> >> >> You are proposing to install more then "best" path locally which may=20 >> actually require substantial changes to the BGP operation. >> >> >> >> How do you control which paths are to be installed let's say which 2=20 >>out of N ? The multipath checks are not really helpful here. >> >> >> >> It's an interesting question if we in general agree to install=20 >> multiple paths in flowspec SAFI for the exact same NLRI ? >> >> >> >> Regards, >> >> R. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Aug 27, 2013 at 11:37 PM, Pradosh Mohapatra=20 >> >> wrote: >> >> Hi Kaliraj, >> >> >> >> Suggest you use add-path: send two paths for the flow, one with=20 >>next-hop X >> >> and redirect action, the other with next-hop Y and mirror action. >> >> >> >> - Pradosh >> >> >> >> ________________________________ >> >> From: Kaliraj Vairavakkalai >> To: "Simpson, Adam (Adam)" ; >> "ju1738@att.com" ; "pmohapat@cisco.com" >> ; "djsmith@cisco.com" ;=20 >>"Henderickx, Wim (Wim)" ;=20 >>"mtexier@arbor.net" >> >> Cc: Jeff Haas ; "idr@ietf.org" >> Sent: Tuesday, August 27, 2013 10:55 AM >> Subject: Re: [Idr] Flowspec, coexistance of redirect and mirror=20 >>actions >> >> >> Yes Adam, the original flow with destination A is steered/moved to=20 >>new destination B (e.g. scrubber device) while simultaneously copy of=20 >>this flow sent to a new destination C (e.g. for LI) >> >> The devices doing the scrubbing and LI may be different (based on=20 >>devices' >> capability, load-balancing requirement etc), was the thought behind=20 >>my question. >> >> Thanks, >> Kaliraj >>> -----Original Message----- >>> From: Simpson, Adam (Adam) [mailto:adam.simpson@alcatel-lucent.com] >>> Sent: Tuesday, August 27, 2013 10:19 AM >>> To: Kaliraj Vairavakkalai; ju1738@att.com; pmohapat@cisco.com;=20 >>> djsmith@cisco.com; Henderickx, Wim (Wim); mtexier@arbor.net >>> Cc: Jeff Haas; idr@ietf.org >>> Subject: Re: Flowspec, coexistance of redirect and mirror actions >>> >>> Hi Kaliraj, >>> >>> You are correct; these actions are mutually exclusive according to=20 >>>the current encoding. What does it mean for you to have a flow both=20 >>>moved >>> (redirected) and copied (mirrored)? Do you mean the original flow=20 >>>with destination A is steered/moved to new destination B while at=20 >>>the same time a copy of this flow is sent to a new destination C? I=20 >>>personally have not seen a requirement for this type of compound=20 >>>action but I will leave the other authors to comment as well. >>> >>> -Adam >>> >>> >>> On 2013-08-25 1:13 AM, "Kaliraj Vairavakkalai" >>> wrote: >>> >>> >Hi authors, >>> > >>> >Ref:=20 >>> >http://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 >>> > >>> >If it is desired to perform both "redirect-action" to a nexthop X,=20 >>> >and "mirror-action" to a different nexthop Y simultaneously for the=20 >>> >same flow, how is it achieved? >>> > >>> >It appears the signaling for such a scenario may not be handled by=20 >>> >the mechanisms specified in this draft, unless I am missing something. >>> >Could you pls clarify. >>> > >>> >Thanks >>> >Kaliraj >>> > >>> >>> >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> >> >>=20 >>______________________________________________________________________ >>___ ________________________________________________ >> >> >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc >> >> pas etre diffuses, exploites ou copies sans autorisation. Si vous=20 >>avez recu ce message par erreur, veuillez le signaler >> >> a l'expediteur et le detruire ainsi que les pieces jointes. Les=20 >> messages electroniques etant susceptibles d'alteration, >> >> Orange decline toute responsabilite si ce message a ete altere,=20 >>deforme ou falsifie. Merci. >> >> >> >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; >> >> they should not be distributed, used or copied without authorisation. >> >> If you have received this email in error, please notify the sender=20 >> and delete this message and its attachments. >> >> As emails may be altered, Orange is not liable for messages that have=20 >>been modified, changed or falsified. >> >> Thank you. >> >> >> >>=20 >>______________________________________________________________________ >>___ ________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20=20 >>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >>exploites ou copies sans autorisation. Si vous avez recu ce message=20 >>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >>que les pieces jointes. Les messages electroniques etant susceptibles=20 >>d'alteration, Orange decline toute responsabilite si ce message a ete=20 >>altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >>privileged information that may be protected by law; they should not=20 >>be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender=20 >>and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have=20 >>been modified, changed or falsified. >> Thank you. > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Feb 20 13:26:57 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF461A0306 for ; Thu, 20 Feb 2014 13:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D88nOb09hLQU for ; Thu, 20 Feb 2014 13:26:53 -0800 (PST) Received: from nm31.bullet.mail.ne1.yahoo.com (nm31.bullet.mail.ne1.yahoo.com [98.138.229.24]) by ietfa.amsl.com (Postfix) with ESMTP id 183811A02E6 for ; Thu, 20 Feb 2014 13:26:51 -0800 (PST) Received: from [127.0.0.1] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2014 21:26:48 -0000 Received: from [98.138.100.111] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2014 21:23:58 -0000 Received: from [98.137.12.188] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 20 Feb 2014 21:23:58 -0000 Received: from [98.137.12.208] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 20 Feb 2014 21:23:57 -0000 Received: from [127.0.0.1] by omp1016.mail.gq1.yahoo.com with NNFMP; 20 Feb 2014 21:23:57 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 905770.14371.bm@omp1016.mail.gq1.yahoo.com Received: (qmail 55750 invoked by uid 60001); 20 Feb 2014 21:23:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392931437; bh=7XQ1zX4zWfZSfr9xQS72DiV0m1R+o8m01WoIcLVX2Ro=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xFFqL5HrAjIa4PPRRQUHFF6YIZaSYpsXRJVFMnNZA26fkmQlFgILej/GfX/r9PRBrO6VCNiB0OPX8QdQwPpk1rsHJwrsiiRmA0crQIy9Q69qoA239rhHbzYx/+O9BqVL+xYLzBOO5lfTyo7v2Dl3H4Tq0VTdPvF+dENLBOEPt/E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=gdXrPSnTIXTGqEDiFV0P7vFjiN9XKE5hMr9Ycbaiva+rhVWsn2p0AZcQuCoMU8CTTbODOuOz0f6eA6GpF24K7RqN4WcMLPAmBqEv71/HJwYw+IM48UlVX/GxDDCnS/gdkCU5MIJbwqqZU2MWIT5NkyX7r2Z1ioa8PUSirYrctsQ=; X-YMail-OSG: 4yAVf_cVM1mgYN_DeNFw2QJ3jNonNCFQGq6IgL9EGShnzxX 6k6qUvpRw56jqjLxJ7rqvmX1oPyGOY5A584bbTtrWYB.alvTFqX_qUW51x.o kM4ePWzzm1utz27_LvTrkNrHUDLqFZjt0PJFsgB8WfxGa8jarR3dJZYmgt8h S.0VI.Assd_UnKkyzFe.EtD1FhZDPjkOCGDGzKvIH_Va3a4hlpQCi5zwWs9Y gV0hkpAQ0dMNuABHdVlJI50n1WQ04O0sWRf4gmRshLICszg2G2RdqDnIePAS ADA4VzumTSntei5is3cWY6PZ7V8WDJ7dGC.ttG_vhzMd2oI7XMN3iQXis_iN mMLe0TNIgfTKBU7WtgbbUi5G3AoATwOTkWS9hK6bGadaNhWIi9FfzQSolqrS x3vko1PP4XKtiVT1U0V1Ja4y3_vzJWyODeR1k8gGmQz1R_GMD54vkUt3MAPJ SP6P1UVEy1fHgKO6r5iUqY2BgnYZs8l4DUreAxd5Hi9oq9iTSNY6Q0Ojbygd 4DGQxcuUGFDfKiUMifIN5.WkGelkuVySVA8ZFDeTr9Q-- Received: from [172.2.241.104] by web164804.mail.gq1.yahoo.com via HTTP; Thu, 20 Feb 2014 13:23:57 PST X-Rocket-MIMEInfo: 002.001, SGkgT25kcmVqLAoKClRoZSBjb3JyZWN0IGltcGxlbWVudGF0aW9uIGFwcHJvYWNoIGlzIHdoYXQgeW91IGRlc2NyaWJlIGluICgzKSBiZWxvdyAtIG1vdmUgdGhlIEZTTXMgaW5kZXBlbmRlbnRseSB0aWxsIHlvdSBjYW4gcmVzb2x2ZSB0aGUgY29sbGlzaW9uIChhZnRlciBPcGVuQ29uZmlybSBzdGF0ZSkuIEkgY2FuIHNlZSBob3cgaXQgY2FuIGNvbmZsaWN0IHdpdGggc2VjLiA4LjIuMSBzdGF0ZW1lbnQ6CgrCoMKgwqDCoCBBIEJHUCBpbXBsZW1lbnRhdGlvbiB3aWxsIGhhdmUsIGF0IG1vc3QsIG9uZSBGU00BMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <20140214202736.GB15489@localhost> Message-ID: <1392931437.84362.YahooMailNeo@web164804.mail.gq1.yahoo.com> Date: Thu, 20 Feb 2014 13:23:57 -0800 (PST) From: Pradosh Mohapatra To: Ondrej Zajicek , "idr@ietf.org" In-Reply-To: <20140214202736.GB15489@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1873154574-1280386375-1392931437=:84362" Archived-At: http://mailarchive.ietf.org/arch/msg/idr/eOByqDE_MpNHY2AsOVuBaOWXT3o Subject: Re: [Idr] BGP FSM vague and contradictory w.r.t. collisions X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Pradosh Mohapatra List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 21:26:55 -0000 --1873154574-1280386375-1392931437=:84362 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ondrej,=0A=0A=0AThe correct implementation approach is what you describe= in (3) below - move the FSMs independently till you can resolve the collis= ion (after OpenConfirm state). I can see how it can conflict with sec. 8.2.= 1 statement:=0A=0A=A0=A0=A0=A0 A BGP implementation will have, at most, one= FSM for =0A=0A=A0=A0=A0=A0 each configured peering, plus one FSM for each = incoming =0A=0A=A0=A0=A0=A0 TCP connection for which the peer has not yet b= een =0A=0A=A0=A0=A0=A0 identified.=0A=0A=0Athat's being pedantic IMO ;)=0A= =0A=0A- Pradosh=0A=0A=0A=0AOn Friday, February 14, 2014 11:54 AM, Ondrej Za= jicek wrote:=0A=0AHi=0A=0ARFC 4721 is rather vague= w.r.t. BGP connection collisions and=0Arelated FSMs. Paragraph 8.2.1. spec= ifies:=0A=0A=A0=A0=A0A BGP implementation will have, at most, one FSM for e= ach configured=0A=A0=A0=A0peering, plus one FSM for each incoming TCP conne= ction for which the=0A=A0=A0=A0peer has not yet been identified.=A0 Each FS= M corresponds to exactly=0A=A0=A0=A0one TCP connection.=0A=0AThat means tha= t we have a 'primary' FSM for a peer and 'auxiliary' FSM=0Awhen a new incom= ing TCP connection is accepted. Question is where these=0Atwo FSMs get merg= ed. According to the mentioned paragraph, auxiliary FSM=0Ais here only when= 'the peer has not yet been identified', which means=0Athat it is in OpenSe= nt state (since in OpenConfirm, the identity /=0Arouter ID of the peer is k= nown). What happens when the auxiliary FSM=0Achanges from OpenSent to OpenC= onfirm? That depends on the state of=0Athe primary FSM:=0A=0AIf the primary= FSM is in OpenConfirm or higher, then procedures from=0A6.8. BGP Connectio= n Collision Detection applies, one connection is=0Aclosed and one FSM remai= ns, so there is no problem.=0A=0ABut what happens if the primary FSM is in = OpenSent or even in a lower=0Astate?=A0 Par. 8.2.1 mentioned above implicit= ly says that one FSM has=0Ato be eliminated, but Par. 6.8. does not handle = such case and FSM=0Adescription in 8.2.2. gives some clues that it should s= till exist,=0Ae.g. events 16 (outgoing TCP accepted) and 17 (incoming TCP a= ccepted)=0Aare specified in higher states for 'the other connection', but i= f there=0Ais no FSM in state Connect, then event 16 cannot happen and only = event=0A17 is relevant for 'the other connection'.=0A=0AI see three possibl= e ways how to handle this situation (auxiliary FSM in=0AOpenSent->OpenConfi= rm transition, while primary FSM state <=3D OpenSent):=0A=0A1) Kill primary= FSM and related state (and replace it with auxiliary=0AFSM). This is consi= stent with 8.2.1., but it is against the spirit of=0A6.8. and killing an ou= tgoing connection which is already in OpenSent=0Astate is not specified any= where in 8.2.2. and probably not a good idea.=0A=0A2) Kill primary FSM (and= related state) when it is in Connect or Active=0Astate, but keep it when i= t is in OpenSent state. This is not strictly=0Aconsistent with 6.8., 8.2.1.= , or 8.2.2., but it is probably most=0Acompatible and least intrusive chang= e.=0A=0A3) Keep primary FSM independently to auxiliary FSM and continue it = until=0Ait advances fo OpenConfirm, then solve it according to 6.8.. This i= s=0Aconsistent with 8.2.2., but hard violation of 8.2.1.. It also expands= =0Acollision window so most BGP session establishment attempts would contai= n=0Acollision handling.=0A=0AWhat do you think is a proper way for a BGP im= plementation to handle this case?=0A=0A-- =0AOndrej 'SanTiago' Zajicek (ema= il: santiago@crfreenet.org)=0A_____________________________________________= __=0AIdr mailing list=0AIdr@ietf.org=0Ahttps://www.ietf.org/mailman/listinf= o/idr=A0 --1873154574-1280386375-1392931437=:84362 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAlL+fDgACgkQw1GB2RHercN7PwCeO4QkjsjT5HoUVQowigVm1FZB RLsAnRWOPsjvihxoU8DClKRYBF/zg29L =bQko -----END PGP SIGNATURE----- --1873154574-1280386375-1392931437=:84362-- From nobody Sun Feb 23 16:47:05 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3C91A076E; Sun, 23 Feb 2014 16:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIDArSwrNb8W; Sun, 23 Feb 2014 16:47:02 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3491A019F; Sun, 23 Feb 2014 16:47:02 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1O0kxQh052366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 24 Feb 2014 00:47:01 GMT (envelope-from joelja@bogus.com) Message-ID: <530A967D.1080608@bogus.com> Date: Sun, 23 Feb 2014 16:46:53 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Randy Bush , Jeffrey Haas References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nfcj2iFS4m2ipnLAuuK0icEION5EKSHtj" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 24 Feb 2014 00:47:02 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/azCbPlanxP_OVn2YEjv_UtR8BzM Cc: idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 00:47:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nfcj2iFS4m2ipnLAuuK0icEION5EKSHtj Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/19/14, 6:35 PM, Randy Bush wrote: >> What I would instead suggest is finding a mechanism by which the >> unique router-ID can be mapped easily to such addresses. I don't >> believe that BGP is the right place to do this. >=20 > we need a name to address mapping mechanism. let's all think about > that. routerid rr-type anyone? that actually doesn't sound like a totally appalling idea. :p > randy >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --nfcj2iFS4m2ipnLAuuK0icEION5EKSHtj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMKln4ACgkQ8AA1q7Z/VrIC1wCfYAv+uIMS9aTpmLvQQuEpsrY8 ZxIAn0ENM4Z40aS5Bxsi1l7OwyaRVvOp =Fazj -----END PGP SIGNATURE----- --nfcj2iFS4m2ipnLAuuK0icEION5EKSHtj-- From nobody Mon Feb 24 07:08:41 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04861A008E; Mon, 24 Feb 2014 07:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIuGXG0EnHrw; Mon, 24 Feb 2014 07:08:36 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9F51A009A; Mon, 24 Feb 2014 07:08:36 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 20D3CC307; Mon, 24 Feb 2014 10:08:36 -0500 (EST) Date: Mon, 24 Feb 2014 10:08:36 -0500 From: Jeffrey Haas To: joel jaeggli Message-ID: <20140224150836.GC21344@pfrc> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> <530A967D.1080608@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530A967D.1080608@bogus.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/YTQVzfEbjt-va-zaX3QR4y1sL-Y Cc: V6 Ops List , idr wg Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 15:08:37 -0000 On Sun, Feb 23, 2014 at 04:46:53PM -0800, joel jaeggli wrote: > On 2/19/14, 6:35 PM, Randy Bush wrote: > > we need a name to address mapping mechanism. let's all think about > > that. > > routerid rr-type anyone? > > that actually doesn't sound like a totally appalling idea. The idea of requiring DNS to be working as a tool to manage your routing plane seems rather abhorrent to me. If routing isn't working well, neither will DNS. -- Jeff From nobody Mon Feb 24 07:18:21 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7459C1A00EC; Mon, 24 Feb 2014 07:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEBtyl8H2y9W; Mon, 24 Feb 2014 07:18:16 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 048541A00E8; Mon, 24 Feb 2014 07:18:11 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id at1so3551585iec.34 for ; Mon, 24 Feb 2014 07:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YMCBp4TEfzKMVnQZF1WvXLBDATvcJP4+kjxGW2M+mQg=; b=t1jNz/wjMyPYgmbUHR6TBV8pN+42w0Jtw/qiCjK/r0uiT9ZD+acNHRZedJmnwxdW5E HTSy/fiR5akO30yqUfElOIreWjBCBD6TzPbquYZf3JtCXsuRFRxGLUgc6RzZvQ5A2e+g RR4Uz+XBr1URqhLJLFuB/omzMT0A3t+1SkhO3BAFcgG2yZMRP1oSsS0vMdlYLDh0AeqE fLTNemAoHSdykhjtoPRBpxPPaBgdgXuNiLpPst5xlX42tGIDNb9bM0lmkwxjzc4KVaB9 WXeCS3+FNP5ShjVYfTTGcD2FwGzxUr6PBfO0yMitanhK4xraTLAibGVwR7DArEv8WpZC Lm6Q== MIME-Version: 1.0 X-Received: by 10.50.29.70 with SMTP id i6mr14013073igh.21.1393255091266; Mon, 24 Feb 2014 07:18:11 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.251.199 with HTTP; Mon, 24 Feb 2014 07:18:11 -0800 (PST) In-Reply-To: <20140224150836.GC21344@pfrc> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> <530A967D.1080608@bogus.com> <20140224150836.GC21344@pfrc> Date: Mon, 24 Feb 2014 16:18:11 +0100 X-Google-Sender-Auth: vmhGmkr_y49wI_tgQCbZmPJOXY4 Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/nJ9rD8Vkp3dfBL9Wo9rUTdkVlAY Cc: joel jaeggli , idr wg , V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 15:18:17 -0000 Jeff, Even outside of BGP router_id topic for operational reasons resolving router's IP addresses (especially those v6) to hostnames and to interface names of the routers in anyone network would seem to me like rather a useful idea. And that not on a dedicated management linux station but on all routers. When you do show command do you prefer to see bunch of digits or much less and more meaningful ASCII strings ? Here you have a choice .. flood it by all protocols or push local hosts files. Since config is automated I do not see much issue in keep up to date hosts file of your network on all boxes. Thx, r. On Mon, Feb 24, 2014 at 4:08 PM, Jeffrey Haas wrote: > On Sun, Feb 23, 2014 at 04:46:53PM -0800, joel jaeggli wrote: >> On 2/19/14, 6:35 PM, Randy Bush wrote: >> > we need a name to address mapping mechanism. let's all think about >> > that. >> >> routerid rr-type anyone? >> >> that actually doesn't sound like a totally appalling idea. > > The idea of requiring DNS to be working as a tool to manage your routing > plane seems rather abhorrent to me. If routing isn't working well, neither > will DNS. > > -- Jeff > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 24 07:51:32 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3CD1A015D; Mon, 24 Feb 2014 07:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ_T5uK788rl; Mon, 24 Feb 2014 07:51:28 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 590CD1A0140; Mon, 24 Feb 2014 07:51:28 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E9FEBC307; Mon, 24 Feb 2014 10:51:27 -0500 (EST) Date: Mon, 24 Feb 2014 10:51:27 -0500 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140224155127.GD21344@pfrc> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> <530A967D.1080608@bogus.com> <20140224150836.GC21344@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/T2Dv95Yo-IOnC8yNQTCVwyra3qw Cc: joel jaeggli , V6 Ops List , idr wg Subject: Re: [Idr] [v6ops] BGP Identifier X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 15:51:30 -0000 Robert, On Mon, Feb 24, 2014 at 04:18:11PM +0100, Robert Raszuk wrote: > Here you have a choice .. flood it by all protocols or push local > hosts files. Since config is automated I do not see much issue in keep > up to date hosts file of your network on all boxes. I said DNS, not hosts files. Of course it's possible that rr-types are a more host-file like mechanism than they used to be. -- Jeff From nobody Mon Feb 24 08:12:45 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C891A0708 for ; Sun, 23 Feb 2014 23:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1Ld9ErG6iDx for ; Sun, 23 Feb 2014 23:47:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1421A0361 for ; Sun, 23 Feb 2014 23:47:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 12B1E7FC39D; Sun, 23 Feb 2014 23:47:45 -0800 (PST) To: tbates@cisco.com, enkechen@cisco.com, rchandra@sonoasystems.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20140224074745.12B1E7FC39D@rfc-editor.org> Date: Sun, 23 Feb 2014 23:47:45 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/idr/pP5MegQbCo4tb3RjeCDvE2jLaaY X-Mailman-Approved-At: Mon, 24 Feb 2014 08:12:44 -0800 Cc: guban@microsoft.com, rfc-editor@rfc-editor.org, idr@ietf.org Subject: [Idr] [Technical Errata Reported] RFC4456 (3898) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 07:47:47 -0000 The following errata report has been submitted for RFC4456, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4456&eid=3898 -------------------------------------- Type: Technical Reported by: Gunjan Bansal Section: 8 Original Text ------------- ORIGINATOR_ID ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type code 9. This attribute is 4 bytes long and it will be created by an RR in reflecting a route. This attribute will carry the BGP Identifier of the originator of the route in the local AS. A BGP speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already exists. A router that recognizes the ORIGINATOR_ID attribute SHOULD ignore a route received with its BGP Identifier as the ORIGINATOR_ID. CLUSTER_LIST CLUSTER_LIST is a new, optional, non-transitive BGP attribute of Type code 10. It is a sequence of CLUSTER_ID values representing the reflection path that the route has passed. When an RR reflects a route, it MUST prepend the local CLUSTER_ID to the CLUSTER_LIST. If the CLUSTER_LIST is empty, it MUST create a new one. Using this attribute an RR can identify if the routing information has looped back to the same cluster due to misconfiguration. If the local CLUSTER_ID is found in the CLUSTER_LIST, the advertisement received SHOULD be ignored. Corrected Text -------------- Notes ----- Although the guideline exists for the "egress" reflected routes (RR should create ORIGINATOR_ID if none exists, prepend its own ClusterId in CLUSTER_LIST), there is no guideline on how the routes received from iBGP peers be treated if "only one" attribute (ORIGINATOR_ID or CLUSTER_LIST) is present. Should such routes be dropped (Considering them as a malformed routes ?) Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4456 (draft-ietf-idr-rfc2796bis-02) -------------------------------------- Title : BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) Publication Date : April 2006 Author(s) : T. Bates, E. Chen, R. Chandra Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Feb 25 02:16:56 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8598E1A041C for ; Tue, 25 Feb 2014 02:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MWviwaVNbPl for ; Tue, 25 Feb 2014 02:16:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3901A0676 for ; Tue, 25 Feb 2014 02:16:52 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D3D7218C36C for ; Tue, 25 Feb 2014 11:16:50 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B928D23814E for ; Tue, 25 Feb 2014 11:16:50 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 25 Feb 2014 11:16:50 +0100 From: To: "idr@ietf.org" Thread-Topic: draft-gredler-idr-ls-distribution-impl Thread-Index: Ac8yErIAUNAOewcOSk2+9osG8A8YXA== Date: Tue, 25 Feb 2014 10:16:49 +0000 Message-ID: <10025_1393323410_530C6D92_10025_784_5_53C29892C857584299CBF5D05346208A070FDC28@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/HmaFHi_vByLi9DVA2pksdMtbkjM Subject: [Idr] draft-gredler-idr-ls-distribution-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 10:16:54 -0000 Hi Hannes, Balaji, Saikat, Manish Many thanks for the detailed hence useful implementation report. I'm not that familiar with implementation reports so please excuse some pos= sibly naive comments below: > the BGP Link-State Information Distribution protocol as defined in [I-D.i= etf-idr-ls-distribution] Draft could change over the time. I guess it could still change. So what about indicating the draft version number which is considered to be= the reference/spec? > Release: IOS-XR > Release: JUNOS Same comments for OS version. > 4. Link NLRI TLV support > +--------------+--------+-------+-----+ > | | IOS-XR | JUNOS | TBD | > +--------------+--------+-------+-----+ > | Rcv.TLV 256 | YES | YES | --- | [...] > | Rcv.TLV 513 | --- | YES | --- | > | Snd.TLV 513 | --- | NO | --- | For the Cisco IOS-XR data, what does "---" means? Yes? No? Don't know? > In particular we have tested our interoperability with Cisco Systems, Inc= . IOS-XR implementation. Good. Could you please share some details about the result of the tests? So= mething likes: all NLRI subtypes and NLRI TLV supported by both implementat= ions (as per this document) were found to be interoperable. --- On a side note, I'm not sure to see the value of section 7.3 "TBD Implement= ation", nor sentence like "The Cisco Systems, Inc. IOS-XR implementation sh= ould be interoperable with other vendor BGP-LS Protocol implementations" Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Feb 28 01:38:58 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97681A07AB for ; Fri, 28 Feb 2014 01:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1_pxz9BihHO for ; Fri, 28 Feb 2014 01:38:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 96CCE1A079E for ; Fri, 28 Feb 2014 01:38:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBP43833; Fri, 28 Feb 2014 09:38:46 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 09:38:29 +0000 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 09:38:45 +0000 Received: from peky1z001750051 (10.111.80.111) by smtpscn.huawei.com (10.82.67.191) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Feb 2014 17:38:41 +0800 From: Zhuangshunwan To: Date: Fri, 28 Feb 2014 17:38:40 +0800 Message-ID: <000301cf3468$dd72dfd0$98589f70$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CF34AB.EB961FD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac80aNzOu3rtpcNeQiya0Li6mkTuoA== Content-Language: zh-cn X-Originating-IP: [10.111.80.111] X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/idr/dsszihhu3AWLgpgY83tccDY20eA Subject: [Idr] [IDR] Comment to draft-ietf-idr-ls-distribution-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 09:38:54 -0000 ------=_NextPart_000_0004_01CF34AB.EB961FD0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Authors, I have a comment, see inline. =20 3.2.3.2. IP Reachability Information =20 The IP Reachability Information is a mandatory TLV that contains one IP address prefix (IPv4 or IPv6) originally advertised in the IGP topology. Its purpose is to glue a particular BGP service NLRI vi virtue of its BGP next-hop to a given Node in the LSDB. A router SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. The format of the IP Reachability Information TLV is shown in the following figure: =20 =20 =20 =20 =20 =20 =20 Gredler, et al. Expires May 22, 2014 [Page 17] =20 Internet-Draft Link-State Info Distribution using BGP November 2013 =20 =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | IP Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 14: IP Reachability Information TLV Format =20 The Type and Length fields of the TLV are defined in Table 4. The following two fields determine the address-family reachability information. The 'Prefix Length' field contains the length of the prefix in bits. The 'IP Prefix' field contains the most significant octets of the prefix; i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix length 25 up to 32, etc. =20 =20 =20 Vincent=A3=BA =20 For multiple IP address prefixes, if Local Node Descriptor and BGP-LS = Attribute are the same, maybe we can put multiple prefixes into one=20 IP Reachability Information TLV? =20 In this way, some overhead bytes could be cut. =20 For example: =20 One IP address prefix per IP Reachability Information TLV, we can see = multiple Prefix NLRI in one bgp update message: First Prefix NLRI: 00 03 --->Type =3D 3: IPv4 Topology Prefix NLRI 00 30=20 02=20 00 00 00 00 00 00 00 01=20 01 00 --->256, Local Node Descriptors 00 1a=20 02 00 --->512, Autonomous System 00 04=20 00 00 00 64=20 02 01 --->513, BGP-LS Identifier=20 00 04=20 58 58 58 58=20 02 03 --->515, IGP Router-ID 00 06=20 00 00 00 00 00 58=20 01 09 --->265, IP Reachability Information 00 05=20 20 58 58 58 58 --->88.88.88.88/32 =20 Second Prefix NLRI: 00 03 --->Type =3D 3: IPv4 Topology Prefix NLRI 00 2f=20 02=20 00 00 00 00 00 00 00 01=20 01 00=20 00 1a=20 02 00=20 00 04=20 00 00 00 64=20 02 01=20 00 04=20 58 58 58 58=20 02 03=20 00 06=20 00 00 00 00 00 58=20 01 09=20 00 04=20 18 c8 01 01 --->200.1.1.0/24 =20 Above two Prefix NLRIs can be combined into one Prefix NLRI. Multiple prefixes in one IP Reachability Information TLV: 00 03 --->Type =3D 3: IPv4 Topology Prefix NLRI 00 34=20 02=20 00 00 00 00 00 00 00 01=20 01 00=20 00 1f=20 02 00=20 00 04=20 00 00 00 64=20 02 01=20 00 04=20 58 58 58 58=20 02 03=20 00 06=20 00 00 00 00 00 58=20 01 09=20 00 09 ---> Prefix Length of multiple prefix 20 58 58 58 58 --->88.88.88.88/32=20 18 c8 01 01 --->200.1.1.0/24 =20 I understand aright? =20 Regards, Vincent =20 ------=_NextPart_000_0004_01CF34AB.EB961FD0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear = Authors,

I have a comment, see inline.

 

3.2.3.2.  IP Reachability = Information

 

   The IP Reachability Information is a mandatory = TLV that contains one

   IP address prefix (IPv4 or IPv6) originally = advertised in the IGP

   topology.  Its purpose is to glue a = particular BGP service NLRI vi

   virtue of its BGP = next-hop to a given Node in the LSDB.  A = router

   SHOULD advertise an IP Prefix NLRI for each of = its BGP Next-hops.

   The format of the IP Reachability Information = TLV is shown in the

   following figure:

 

 

 

 

 

 

 

Gredler, et = al.           Expires = May 22, = 2014           &nb= sp;     [Page 17]


 

Internet-Draft   = Link-State Info Distribution using BGP    November = 2013

 

 

    = 0            =        = 1            =        = 2            =        3

    0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   = |            =   = Type           &nb= sp; = |            = = Length            = |

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | = Prefix Length | IP Prefix = (variable)          &nb= sp;           &nbs= p;  //

   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

          =    Figure 14: IP Reachability Information TLV = Format

 

   The Type and Length fields of the TLV are = defined in Table 4.  The

   following two fields = determine the address-family reachability

   information.  The = 'Prefix Length' field contains the length of the

   prefix in bits.  = The 'IP Prefix' field contains the most = significant

   octets of the prefix; i.e., 1 octet for prefix = length 1 up to 8, 2

   octets for prefix length 9 to 16, 3 octets for = prefix length 17 up to

   24 and 4 octets for prefix length 25 up to 32, = etc.

  

   

   

   Vincent=A3=BA

 

   For multiple IP address prefixes, if Local = Node Descriptor and BGP-LS

   Attribute are the = same, maybe we can put multiple prefixes into one =

   IP Reachability Information = TLV?

  

   In this way, some = overhead bytes could be cut.

   =

   For example:

   =

   One IP address prefix per IP Reachability = Information TLV, we can see

   multiple Prefix = NLRI in one bgp update message:

   First Prefix = NLRI:

   00 03 --->Type =3D 3: IPv4 Topology Prefix = NLRI

   00 30

   02 =

   00 00 00 00 00 00 00 01 =

   01 00 --->256, Local Node = Descriptors

   00 1a

   02 00 --->512, = Autonomous System

   00 04

   00 00 00 64 =

   02 01 --->513, BGP-LS Identifier =

   00 04

   58 58 58 58 =

   02 03 --->515, IGP = Router-ID

   00 06

   00 00 00 00 00 58 =

   01 09 --->265, IP Reachability = Information

   00 05

   20 58 58 58 58 = --->88.88.88.88/32

 

   Second Prefix NLRI:

   00 03 --->Type =3D = 3: IPv4 Topology Prefix NLRI

   00 2f =

   02

   00 00 00 00 00 00 = 00 01

   01 00

   00 1a =

   02 00

   00 04 =

   00 00 00 64

   02 01 =

   00 04

   58 58 58 58 =

   02 03

   00 06 =

   00 00 00 00 00 58 =

   01 09

   00 04 =

   18 c8 01 01 = --->200.1.1.0/24

  

   Above two Prefix = NLRIs can be combined = into one Prefix NLRI.

   Multiple prefixes in = one IP Reachability Information TLV:

   00 03 --->Type =3D = 3: IPv4 Topology Prefix NLRI

   00 34 =

   02

   00 00 00 00 00 00 = 00 01

   01 00

   00 1f =

   02 00

   00 04 =

   00 00 00 64

   02 01 =

   00 04

   58 58 58 58 =

   02 03

   00 06 =

   00 00 00 00 00 58 =

   01 09

   00 09 ---> = Prefix Length of multiple prefix

   20 58 58 58 58 = --->88.88.88.88/32

   18 c8 01 01 = --->200.1.1.0/24

  

   I understand = aright?

  

Regards,

Vincent

 

------=_NextPart_000_0004_01CF34AB.EB961FD0-- From nobody Fri Feb 28 08:03:15 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FBD1A02D4 for ; Fri, 28 Feb 2014 08:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAtd7KtbwFAZ for ; Fri, 28 Feb 2014 08:03:10 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A52191A0301 for ; Fri, 28 Feb 2014 08:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20367; q=dns/txt; s=iport; t=1393603389; x=1394812989; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sm2cRMpfNLQtY7hV1pQi9FG8Al7pxrFcfEPf7SNSfoA=; b=G3ITZAfr7vrboGQXPJOglyPAO8QnkVLhxdUSr9imvO+ZxCv4fDFhVpBn VbuDfl8U2vMdehDRhuiQrlrue85MqKA+tQqJi97KIJ5an0oxu06BOaNMz JRQnc6lD2fkiF41OgsdMoTnJRPCfKkFsohw8sUS84cjZI11buINqXTruX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAMuyEFOtJV2c/2dsb2JhbABZgkJEO1eDA74cgRQWdIIlAQEBBCEBBQZcAgEIEQQBAQsFEQcCAwIyFAkIAQEEARIIh3GOWpwCAaBvF44kNwEGgmU4gRQElE+WFoMtgio X-IronPort-AV: E=Sophos;i="4.97,562,1389744000"; d="scan'208,217";a="307229068" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 28 Feb 2014 16:03:08 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1SG37WS019317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 16:03:08 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.119]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 28 Feb 2014 10:03:07 -0600 From: "Saikat Ray (sairay)" To: Zhuangshunwan , "idr@ietf.org" Thread-Topic: [Idr] [IDR] Comment to draft-ietf-idr-ls-distribution-04.txt Thread-Index: Ac80aNzOu3rtpcNeQiya0Li6mkTuoAANISIA Date: Fri, 28 Feb 2014 16:03:07 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A11B3B4FD@xmb-rcd-x13.cisco.com> References: <000301cf3468$dd72dfd0$98589f70$@com> In-Reply-To: <000301cf3468$dd72dfd0$98589f70$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.84.70] Content-Type: multipart/alternative; boundary="_000_8ED5B0B0F5B4854A912480C1521F973A11B3B4FDxmbrcdx13ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/idr/jx1XNPgn_it5XtfVr3F4967ircw Subject: Re: [Idr] [IDR] Comment to draft-ietf-idr-ls-distribution-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 16:03:14 -0000 --_000_8ED5B0B0F5B4854A912480C1521F973A11B3B4FDxmbrcdx13ciscoc_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable If you do that, you will not be able to withdraw a single prefix (or a subs= et of prefixes) from the group as it is in the key portion - you would need= to send withdraw for first NLRI with the previous group, and readvertise (= a new) NLRI with the new group (or possibly in the other order). We decided= against this complexity (also note that order of withdraw and advertisemen= t is not guaranteed which could create routing glitches). From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Zhuangshunwan Sent: Friday, February 28, 2014 1:39 AM To: idr@ietf.org Subject: [Idr] [IDR] Comment to draft-ietf-idr-ls-distribution-04.txt Dear Authors, I have a comment, see inline. 3.2.3.2. IP Reachability Information The IP Reachability Information is a mandatory TLV that contains one IP address prefix (IPv4 or IPv6) originally advertised in the IGP topology. Its purpose is to glue a particular BGP service NLRI vi virtue of its BGP next-hop to a given Node in the LSDB. A router SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. The format of the IP Reachability Information TLV is shown in the following figure: Gredler, et al. Expires May 22, 2014 [Page 17] Internet-Draft Link-State Info Distribution using BGP November 2013 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | IP Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: IP Reachability Information TLV Format The Type and Length fields of the TLV are defined in Table 4. The following two fields determine the address-family reachability information. The 'Prefix Length' field contains the length of the prefix in bits. The 'IP Prefix' field contains the most significant octets of the prefix; i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix length 25 up to 32, etc. Vincent=1B$B!'=1B(B For multiple IP address prefixes, if Local Node Descriptor and BGP-LS Attribute are the same, maybe we can put multiple prefixes into one IP Reachability Information TLV? In this way, some overhead bytes could be cut. For example: One IP address prefix per IP Reachability Information TLV, we can see multiple Prefix NLRI in one bgp update message: First Prefix NLRI: 00 03 --->Type =3D 3: IPv4 Topology Prefix NLRI 00 30 02 00 00 00 00 00 00 00 01 01 00 --->256, Local Node Descriptors 00 1a 02 00 --->512, Autonomous System 00 04 00 00 00 64 02 01 --->513, BGP-LS Identifier 00 04 58 58 58 58 02 03 --->515, IGP Router-ID 00 06 00 00 00 00 00 58 01 09 --->265, IP Reachability Information 00 05 20 58 58 58 58 --->88.88.88.88/32 Second Prefix NLRI: 00 03 --->Type =3D 3: IPv4 Topology Prefix NLRI 00 2f 02 00 00 00 00 00 00 00 01 01 00 00 1a 02 00 00 04 00 00 00 64 02 01 00 04 58 58 58 58 02 03 00 06 00 00 00 00 00 58 01 09 00 04 18 c8 01 01 --->200.1.1.0/24 Above two Prefix NLRIs can be combined into one Prefix NLRI. Multiple prefixes in one IP Reachability Information TLV: 00 03 --->Type =3D 3: IPv4 Topology Prefix NLRI 00 34 02 00 00 00 00 00 00 00 01 01 00 00 1f 02 00 00 04 00 00 00 64 02 01 00 04 58 58 58 58 02 03 00 06 00 00 00 00 00 58 01 09 00 09 ---> Prefix Length of multiple prefix 20 58 58 58 58 --->88.88.88.88/32 18 c8 01 01 --->200.1.1.0/24 I understand aright? Regards, Vincent --_000_8ED5B0B0F5B4854A912480C1521F973A11B3B4FDxmbrcdx13ciscoc_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

If you d= o that, you will not be able to withdraw a single prefix (or a subset of pr= efixes) from the group as it is in the key portion – you would need t= o send withdraw for first NLRI with the previous group, and readvertise (a new) NLRI with the new group (or possibly in the= other order). We decided against this complexity (also note that order of = withdraw and advertisement is not guaranteed which could create routing gli= tches).

&nb= sp;

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Zhuangshunwan
Sent: Friday, February 28, 2014 1:39 AM
To: idr@ietf.org
Subject: [Idr] [IDR] Comment to draft-ietf-idr-ls-distribution-04.tx= t

 =

Dear Authors,

I have a comment, see inline.

 

3.2.3.2.  IP Reachability Information

 

   The IP Reachability Information is a ma= ndatory TLV that contains one

   IP address prefix (IPv4 or IPv6) origin= ally advertised in the IGP

   topology.  Its purpose is to glue = a particular BGP service NLRI vi

   virtue of its BGP next-hop to a given N= ode in the LSDB.  A router

   SHOULD advertise an IP Prefix NLRI for = each of its BGP Next-hops.

   The format of the IP Reachability Infor= mation TLV is shown in the

   following figure:

 

 

 

 

 

 

 

Gredler, et al.      &= nbsp;    Expires May 22, 2014     &= nbsp;           [Page 17]=


 

Internet-Draft   Link-State Info Distribut= ion using BGP    November 2013

 

 

    0     &n= bsp;            = ; 1            =        2      &= nbsp;            3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6= 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+

   |      &n= bsp;       Type     =         |     &= nbsp;       Length    &nb= sp;       |

   +-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+

   | Prefix Length | IP Prefix (variable)&= nbsp;           &nbs= p;            //

   +-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+

 

        &nbs= p;    Figure 14: IP Reachability Information TLV Format=

 

   The Type and Length fields of the TLV a= re defined in Table 4.  The

   following two fields determine the addr= ess-family reachability

   information.  The 'Prefix Length' = field contains the length of the

   prefix in bits.  The 'IP Prefix' f= ield contains the most significant

   octets of the prefix; i.e., 1 octet for= prefix length 1 up to 8, 2

   octets for prefix length 9 to 16, 3 oct= ets for prefix length 17 up to

   24 and 4 octets for prefix length 25 up= to 32, etc.

  

   

   

   Vincent=1B$B!'=1B(B

 

   For multiple IP address prefixes, if Lo= cal Node Descriptor and BGP-LS

   Attribute are the same, maybe we c= an put multiple prefixes into one

   IP Reachability Information TLV?

  

   In this way, some overhead bytes c= ould be cut.

  

   For example:

  

   One IP address prefix per IP Reach= ability Information TLV, we can see

   multiple Prefix NLRI in one bgp up= date message:

   First Prefix NLRI:

   00 03 --->Type =3D 3: IPv4 Topology = Prefix NLRI

   00 30

   02

   00 00 00 00 00 00 00 01

   01 00 --->256, Local Node Descr= iptors

   00 1a

   02 00 --->512, Autonomous Syste= m

   00 04

   00 00 00 64

   02 01 --->513, BGP-LS Identifie= r

   00 04

   58 58 58 58

   02 03 --->515, IGP Router-ID

   00 06

   00 00 00 00 00 58

   01 09 --->265, IP Reachability = Information

   00 05

   20 58 58 58 58 --->88.88.88.88/= 32

 

   Second Prefix NLRI:

   00 03 --->Type =3D 3: IPv4 Topology = Prefix NLRI

   00 2f

   02

   00 00 00 00 00 00 00 01

   01 00

   00 1a

   02 00

   00 04

   00 00 00 64

   02 01

   00 04

   58 58 58 58

   02 03

   00 06

   00 00 00 00 00 58

   01 09

   00 04

   18 c8 01 01 --->200.1.1.0/24

  

   Above two Prefix NLRIs can be combined into one Prefix NLRI.

   Multiple prefixes in one IP Reachabilit= y Information TLV:

   00 03 --->Type =3D 3: IPv4 Topology = Prefix NLRI

   00 34

   02

   00 00 00 00 00 00 00 01

   01 00

   00 1f

   02 00

   00 04

   00 00 00 64

   02 01

   00 04

   58 58 58 58

   02 03

   00 06

   00 00 00 00 00 58

   01 09

   00 09 ---> Prefix Length of mul= tiple prefix

   20 58 58 58 58 --->88.88.88.88/32

   18 c8 01 01 --->200.1.1.0/24

  

   I understand aright?

  

Regards,

Vincent

 

--_000_8ED5B0B0F5B4854A912480C1521F973A11B3B4FDxmbrcdx13ciscoc_-- From nobody Fri Feb 28 12:53:25 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A051A01DD for ; Fri, 28 Feb 2014 12:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S6Trqtc2TET for ; Fri, 28 Feb 2014 12:53:20 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB441A034B for ; Fri, 28 Feb 2014 12:53:20 -0800 (PST) Received: from mail229-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Fri, 28 Feb 2014 20:53:18 +0000 Received: from mail229-tx2 (localhost [127.0.0.1]) by mail229-tx2-R.bigfish.com (Postfix) with ESMTP id 110161C02A6; Fri, 28 Feb 2014 20:53:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371Ic89bh1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh2a8h839h93fhd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail229-tx2: domain of juniper.net designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=hannes@juniper.net; helo=CH1PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail229-tx2 (localhost.localdomain [127.0.0.1]) by mail229-tx2 (MessageSwitch) id 139362079524692_21285; Fri, 28 Feb 2014 20:53:15 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.251]) by mail229-tx2.bigfish.com (Postfix) with ESMTP id 017FA8E006B; Fri, 28 Feb 2014 20:53:15 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 28 Feb 2014 20:53:14 +0000 Received: from [172.29.65.207] (193.110.55.18) by pod51010.outlook.com (10.255.150.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 28 Feb 2014 20:53:12 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="utf-8" From: Hannes Gredler In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A11B3B4FD@xmb-rcd-x13.cisco.com> Date: Fri, 28 Feb 2014 21:53:10 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <000301cf3468$dd72dfd0$98589f70$@com> <8ED5B0B0F5B4854A912480C1521F973A11B3B4FD@xmb-rcd-x13.cisco.com> To: Zhuangshunwan X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.55.18] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/idr/krM8nWjTxg4DAJkhEd0yi_TCXfI Cc: idr wg Subject: Re: [Idr] [IDR] Comment to draft-ietf-idr-ls-distribution-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 20:53:23 -0000 i'd like to add that 'optimizing' binary protocols in the age of 100gig links and control-plane processors which can suck 100s of MBits of TCP stream data, has long passed the 'boundary of dimishing returns' and hence has no practical relevance. /hannes On Feb 28, 2014, at 5:03 PM, Saikat Ray (sairay) wrote: > If you do that, you will not be able to withdraw a single prefix (or a = subset of prefixes) from the group as it is in the key portion =E2=80=93 = you would need to send withdraw for first NLRI with the previous group, = and readvertise (a new) NLRI with the new group (or possibly in the = other order). We decided against this complexity (also note that order = of withdraw and advertisement is not guaranteed which could create = routing glitches). > =20 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Zhuangshunwan > Sent: Friday, February 28, 2014 1:39 AM > To: idr@ietf.org > Subject: [Idr] [IDR] Comment to draft-ietf-idr-ls-distribution-04.txt > =20 > Dear Authors, > I have a comment, see inline. > =20 > 3.2.3.2. IP Reachability Information > =20 > The IP Reachability Information is a mandatory TLV that contains = one > IP address prefix (IPv4 or IPv6) originally advertised in the IGP > topology. Its purpose is to glue a particular BGP service NLRI vi > virtue of its BGP next-hop to a given Node in the LSDB. A router > SHOULD advertise an IP Prefix NLRI for each of its BGP Next-hops. > The format of the IP Reachability Information TLV is shown in the > following figure: > =20 > =20 > =20 > =20 > =20 > =20 > =20 > Gredler, et al. Expires May 22, 2014 [Page = 17] >=20 > =20 > Internet-Draft Link-State Info Distribution using BGP November = 2013 > =20 > =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Prefix Length | IP Prefix (variable) // > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Figure 14: IP Reachability Information TLV Format > =20 > The Type and Length fields of the TLV are defined in Table 4. The > following two fields determine the address-family reachability > information. The 'Prefix Length' field contains the length of the > prefix in bits. The 'IP Prefix' field contains the most = significant > octets of the prefix; i.e., 1 octet for prefix length 1 up to 8, 2 > octets for prefix length 9 to 16, 3 octets for prefix length 17 up = to > 24 and 4 octets for prefix length 25 up to 32, etc. > =20 > =20 > =20 > Vincent=EF=BC=9A > =20 > For multiple IP address prefixes, if Local Node Descriptor and = BGP-LS > Attribute are the same, maybe we can put multiple prefixes into one > IP Reachability Information TLV? > =20 > In this way, some overhead bytes could be cut. > =20 > For example: > =20 > One IP address prefix per IP Reachability Information TLV, we can = see > multiple Prefix NLRI in one bgp update message: > First Prefix NLRI: > 00 03 --->Type =3D 3: IPv4 Topology Prefix NLRI > 00 30 > 02 > 00 00 00 00 00 00 00 01 > 01 00 --->256, Local Node Descriptors > 00 1a > 02 00 --->512, Autonomous System > 00 04 > 00 00 00 64 > 02 01 --->513, BGP-LS Identifier > 00 04 > 58 58 58 58 > 02 03 --->515, IGP Router-ID > 00 06 > 00 00 00 00 00 58 > 01 09 --->265, IP Reachability Information > 00 05 > 20 58 58 58 58 --->88.88.88.88/32 > =20 > Second Prefix NLRI: > 00 03 --->Type =3D 3: IPv4 Topology Prefix NLRI > 00 2f > 02 > 00 00 00 00 00 00 00 01 > 01 00 > 00 1a > 02 00 > 00 04 > 00 00 00 64 > 02 01 > 00 04 > 58 58 58 58 > 02 03 > 00 06 > 00 00 00 00 00 58 > 01 09 > 00 04 > 18 c8 01 01 --->200.1.1.0/24 > =20 > Above two Prefix NLRIs can be combined into one Prefix NLRI. > Multiple prefixes in one IP Reachability Information TLV: > 00 03 --->Type =3D 3: IPv4 Topology Prefix NLRI > 00 34 > 02 > 00 00 00 00 00 00 00 01 > 01 00 > 00 1f > 02 00 > 00 04 > 00 00 00 64 > 02 01 > 00 04 > 58 58 58 58 > 02 03 > 00 06 > 00 00 00 00 00 58 > 01 09 > 00 09 ---> Prefix Length of multiple prefix > 20 58 58 58 58 --->88.88.88.88/32 > 18 c8 01 01 --->200.1.1.0/24 > =20 > I understand aright? > =20 > Regards, > Vincent > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Feb 28 13:09:26 2014 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6891A0316 for ; Fri, 28 Feb 2014 13:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaDKsFRYpUOH for ; Fri, 28 Feb 2014 13:09:18 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2C64C1A01C8 for ; Fri, 28 Feb 2014 13:09:18 -0800 (PST) Received: from mail197-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Feb 2014 21:09:15 +0000 Received: from mail197-va3 (localhost [127.0.0.1]) by mail197-va3-R.bigfish.com (Postfix) with ESMTP id 91EB44E008A; Fri, 28 Feb 2014 21:09:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zz98dI1a09J1447Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097h186068hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail197-va3: domain of juniper.net designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=hannes@juniper.net; helo=CH1PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail197-va3 (localhost.localdomain [127.0.0.1]) by mail197-va3 (MessageSwitch) id 1393621754940313_10911; Fri, 28 Feb 2014 21:09:14 +0000 (UTC) Received: from VA3EHSMHS037.bigfish.com (unknown [10.7.14.231]) by mail197-va3.bigfish.com (Postfix) with ESMTP id D5FB7A0068; Fri, 28 Feb 2014 21:09:14 +0000 (UTC) Received: from CH1PRD0510HT005.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS037.bigfish.com (10.7.99.47) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 28 Feb 2014 21:09:14 +0000 Received: from juniper.net (193.110.55.18) by pod51010.outlook.com (10.255.150.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 28 Feb 2014 21:09:13 +0000 Date: Fri, 28 Feb 2014 22:09:10 +0100 From: Hannes Gredler To: Message-ID: <20140228210910.GA17710@juniper.net> References: <10025_1393323410_530C6D92_10025_784_5_53C29892C857584299CBF5D05346208A070FDC28@PEXCVZYM11.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <10025_1393323410_530C6D92_10025_784_5_53C29892C857584299CBF5D05346208A070FDC28@PEXCVZYM11.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.55.18] X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/idr/tYNkcCbEgi6TohmiKRkqlFCWq4I Cc: "idr@ietf.org" Subject: Re: [Idr] draft-gredler-idr-ls-distribution-impl X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 21:09:24 -0000 hi bruno, see answers inline; On Tue, Feb 25, 2014 at 10:16:49AM +0000, bruno.decraene@orange.com wrote: | Hi Hannes, Balaji, Saikat, Manish | | Many thanks for the detailed hence useful implementation report. | | I'm not that familiar with implementation reports so please excuse some possibly naive comments below: | | > the BGP Link-State Information Distribution protocol as defined in [I-D.ietf-idr-ls-distribution] | | Draft could change over the time. I guess it could still change. | So what about indicating the draft version number which is considered to be the reference/spec? the relationship between the anchor tag and teh actual draft version is defined in the in the section: --- 11. Informative References [I-D.ietf-idr-ls-distribution] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", draft-ietf-idr-ls-distribution-04 ^^^^^ (work in progress), November 2013. --- | | > Release: IOS-XR | > Release: JUNOS | | Same comments for OS version. the test has been executed with engineering images, we will update it with the actual release numbers as soon as product management has determined release dates, targets platforms etc. | > 4. Link NLRI TLV support | | > +--------------+--------+-------+-----+ | > | | IOS-XR | JUNOS | TBD | | > +--------------+--------+-------+-----+ | > | Rcv.TLV 256 | YES | YES | --- | | [...] | > | Rcv.TLV 513 | --- | YES | --- | | > | Snd.TLV 513 | --- | NO | --- | | | For the Cisco IOS-XR data, what does "---" means? Yes? No? Don't know? 'Don't know' - Manish and Saikat will update this after IETF89; BTW repo is at https://github.com/hannesgredler/draft-gredler-idr-ls-distribution-impl | > In particular we have tested our interoperability with Cisco Systems, Inc. IOS-XR implementation. | | Good. Could you please share some details about the result of the tests? Something likes: all NLRI subtypes and NLRI TLV supported by both implementations (as per this document) were found to be interoperable. stay tuned for the IDR meeting ;-) | On a side note, I'm not sure to see the value of section 7.3 "TBD Implementation", nor sentence like "The Cisco Systems, Inc. IOS-XR implementation should be interoperable with other vendor BGP-LS Protocol implementations" ok, will update this in -01; /hannes