From wwwrun@rfc-editor.org Tue Apr 30 14:14:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25B221F9668 for ; Tue, 30 Apr 2013 14:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn954V1-MahZ for ; Tue, 30 Apr 2013 14:14:06 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9390B21F9A50 for ; Tue, 30 Apr 2013 14:14:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4D1E16210D; Tue, 30 Apr 2013 14:13:36 -0700 (PDT) To: roque@cisco.com, nsheth@juniper.net, raszuk@cisco.com, bgreene@juniper.net, jmauch@us.ntt.net, danny@arbor.net, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20130430211336.4D1E16210D@rfc-editor.org> Date: Tue, 30 Apr 2013 14:13:36 -0700 (PDT) X-Mailman-Approved-At: Wed, 01 May 2013 08:01:23 -0700 Cc: idr@ietf.org, sergey.antipov@nsn.com, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC5575 (3610) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 21:14:18 -0000 The following errata report has been submitted for RFC5575, "Dissemination of Flow Specification Rules". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5575&eid=3610 -------------------------------------- Type: Editorial Reported by: Sergey Antipov Section: 4 Original Text ------------- If a given component type within a prefix in unknown, the prefix in question cannot be used for traffic filtering purposes by the receiver. Since a flow specification has the semantics of a logical AND of all components, if a component is FALSE, by definition it cannot be applied. However, for the purposes of BGP route propagation, this prefix should still be transmitted since BGP route distribution is independent on NLRI semantics. Corrected Text -------------- If a given component type within a prefix is unknown, the prefix in question cannot be used for traffic filtering purposes by the receiver. Since a flow specification has the semantics of a logical AND of all components, if a component is FALSE, by definition it cannot be applied. However, for the purposes of BGP route propagation, this prefix should still be transmitted since BGP route distribution is independent of NLRI semantics. Notes ----- Two minor typos: - If a given component type within a prefix _in_ unknown - independent _on_ 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. -------------------------------------- RFC5575 (draft-ietf-idr-flow-spec-09) -------------------------------------- Title : Dissemination of Flow Specification Rules Publication Date : August 2009 Author(s) : P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From hyojekim@cisco.com Fri May 3 15:31:32 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31DC21F8681 for ; Fri, 3 May 2013 15:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KczOxLyFKSX8 for ; Fri, 3 May 2013 15:31:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D1EEF21F8F1F for ; Fri, 3 May 2013 15:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1415; q=dns/txt; s=iport; t=1367620286; x=1368829886; h=from:to:subject:date:message-id:mime-version; bh=4mKElG7y/0Jo2KsWC6o8ua/jmTHmmCavrnU19fzujNc=; b=fK9j6Maanj/gfi8Ws9A20v3oYWYLTPghEEX0B+gCnR5ZWVeGDtqlpKLL xS0TTLFP9MT4Zmm7H6qrn8eqWypHZ3Mfln3HHLAV5npsWfHEEW9KfBESt 3Jmppo60m+wWhx77KOIn7fTK4nAotTVeAZExpc0IcZqzUlK4hb0hpIdYB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcGAA46hFGtJV2b/2dsb2JhbABQgkMjIb9sehZtB4IWCwEEgQsBCwEeVicEG4gDAQGiBJ9ejwCDKmEDqF6DDYIn X-IronPort-AV: E=Sophos;i="4.87,607,1363132800"; d="scan'208,217";a="206284256" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 03 May 2013 22:31:26 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r43MVQrJ011262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 3 May 2013 22:31:26 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 3 May 2013 17:31:26 -0500 From: "Hyojeong Kim (hyojekim)" To: "idr@ietf.org" Thread-Topic: RFC5575 flow-spec redirect ext-comm encoding Thread-Index: AQHOSE3yCcBlb5LSTUGtq7L7GUj9fw== Date: Fri, 3 May 2013 22:31:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [171.71.139.221] Content-Type: multipart/alternative; boundary="_000_BB7BDBA82647F94A81FE5689A3D2A72812362FE0xmbalnx13ciscoc_" MIME-Version: 1.0 Subject: [Idr] RFC5575 flow-spec redirect ext-comm encoding X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 22:34:51 -0000 --_000_BB7BDBA82647F94A81FE5689A3D2A72812362FE0xmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Reading RFC5575, I have one question regarding "6-byte Route Target" value = of redirect ext-comm. Are we assuming one particular RT type? Or should we consider all possible = types (0x0002, 0x0102, 0x0202) with the 6-byte RT value? Thanks, Hyojeong --_000_BB7BDBA82647F94A81FE5689A3D2A72812362FE0xmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

Reading RFC5575, I have one question regarding "6-byte Route Targ= et" value of redirect ext-comm.  
Are we assuming one particular RT type? Or should we consider all poss= ible types (0x0002, 0x0102, 0x0202) with the 6-byte RT value?

Thanks,
Hyojeong
--_000_BB7BDBA82647F94A81FE5689A3D2A72812362FE0xmbalnx13ciscoc_-- From wwwrun@rfc-editor.org Tue May 14 14:12:11 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF7521F9049; Tue, 14 May 2013 14:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.65 X-Spam-Level: X-Spam-Status: No, score=-101.65 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0e6gWrAz08W; Tue, 14 May 2013 14:12:11 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 236EE21F8FEB; Tue, 14 May 2013 14:12:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1496672E14E; Tue, 14 May 2013 14:12:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130514211206.1496672E14E@rfc-editor.org> Date: Tue, 14 May 2013 14:12:06 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 6938 on Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 21:12:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6938 Title: Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID Author: J. Scudder Status: Standards Track Stream: IETF Date: May 2013 Mailbox: jgs@juniper.net Pages: 3 Characters: 3875 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-deprecate-dpa-etal-00.txt URL: http://www.rfc-editor.org/rfc/rfc6938.txt This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC. This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jrmitche@puck.nether.net Mon May 20 06:02:17 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2308121F8935 for ; Mon, 20 May 2013 06:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5SA8HCwyU5J for ; Mon, 20 May 2013 06:02:16 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 72B6521F88BF for ; Mon, 20 May 2013 06:02:16 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r4KD2DTd018199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 20 May 2013 09:02:13 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r4KD2D5r018198 for idr@ietf.org; Mon, 20 May 2013 09:02:13 -0400 Date: Mon, 20 May 2013 09:02:13 -0400 From: Jon Mitchell To: idr@ietf.org Message-ID: <20130520130213.GA17644@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (puck.nether.net [127.0.0.1]); Mon, 20 May 2013 09:02:13 -0400 (EDT) Subject: [Idr] new draft - reservation of two already reserved ASNs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 13:02:17 -0000 IDR - During the private asn draft process, several times it was recommended that proper documentation of the EXISTING reservations for 65535 and 4294967295 be done, so have posted a draft to try and rectify that. Wanted to get some initial feedback on this draft and add any additional reasoning the group has for these reservations before asking for WG acceptance. Thanks, Jon A new version of I-D, draft-jhjm-idr-last-as-reservations-00.txt has been successfully submitted by Jeffrey Haas and posted to the IETF repository. Filename: draft-jhjm-idr-last-as-reservations Revision: 00 Title: Last Autonomous System (AS) Reservations Creation date: 2013-05-16 Group: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-jhjm-idr-last-as-reservations-00.txt Status: http://datatracker.ietf.org/doc/draft-jhjm-idr-last-as-reservations Htmlized: http://tools.ietf.org/html/draft-jhjm-idr-last-as-reservations-00 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 recommends they not be used by operators. The IETF Secretariat From jhaas@slice.pfrc.org Mon May 20 07:32:34 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCDE21F95F8 for ; Mon, 20 May 2013 07:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m43m8RAelUo for ; Mon, 20 May 2013 07:32:29 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6A91521F95F4 for ; Mon, 20 May 2013 07:32:29 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9DB67C1DC; Mon, 20 May 2013 10:32:28 -0400 (EDT) Date: Mon, 20 May 2013 10:32:28 -0400 From: Jeffrey Haas To: Jon Mitchell Message-ID: <20130520143228.GD22923@pfrc> References: <20130520130213.GA17644@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130520130213.GA17644@puck.nether.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org Subject: Re: [Idr] new draft - reservation of two already reserved ASNs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 14:32:34 -0000 On Mon, May 20, 2013 at 09:02:13AM -0400, Jon Mitchell wrote: > During the private asn draft process, several times it was recommended > that proper documentation of the EXISTING reservations for 65535 and > 4294967295 be done, so have posted a draft to try and rectify that. > Wanted to get some initial feedback on this draft and add any > additional reasoning the group has for these reservations before > asking for WG acceptance. Also, to seed/head off some of the discussion, the justifications in the draft are easy to see as thin in some cases. IMO, we're looking for something that will look historically reasonable but beyond that IANA would rather just have something that says "this doc says they're reserved". Matter of fact, we could simply publish the document and say "they're reserved" and be done with it. Historically, 65535 had been problematic for some implementations. Most of the reason for this to have been problematic was simply bad code and the correspondence of the value with UINT16_MAX/-1 signed int16. One would hope that all such bugs have been banished from the Internet by now. :-) The extension of such thin reasoning to UINT32_MAX is less because bugs have been observed using this value and more from the (these days) typical process of tending to reserve the top and/or bottom code points as magic values for "future extensions". Sometimes such values are never used, sometimes they are. It is, of course, the WG's prerogative to pick whatever justification it would like in such a document. Let us know what text you'd like. :-) -- Jeff From internet-drafts@ietf.org Mon May 20 11:47:13 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21D621F93DE; Mon, 20 May 2013 11:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kukA1rOHOwbJ; Mon, 20 May 2013 11:47:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7E521F95F8; Mon, 20 May 2013 11:47:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130520184708.24786.33056.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 11:47:08 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-custom-decision-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 18:47:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : BGP Custom Decision Process Author(s) : Alvaro Retana Russ White Filename : draft-ietf-idr-custom-decision-03.txt Pages : 8 Date : 2013-05-20 Abstract: The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. This document defines a new Extended Community, called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-custom-decision There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-custom-decision-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-custom-decision-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From farmer@umn.edu Mon May 20 12:05:37 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE13421F937E for ; Mon, 20 May 2013 12:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oetx8qq02Ap6 for ; Mon, 20 May 2013 12:05:30 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3992021F93B9 for ; Mon, 20 May 2013 12:05:28 -0700 (PDT) Received: from mail-ia0-f173.google.com (mail-ia0-f173.google.com [209.85.210.173]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 20 May 2013 14:05:28 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ia0-f173.google.com [209.85.210.173] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f173.google.com with SMTP id k20so7977530iak.32 for ; Mon, 20 May 2013 12:05:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=4k7YV8ISIjpCRPJVoDm87LlNJolKeiSG3O02pb+Olg0=; b=jaOoIMG/DkxdioF8qD00Je3E+p85/IiPQruIp31fF6ywbwnbws/wTUgAJVfpCc90SP 77bJZk5j2vfDrrAYHISsqC1/2jta4ARSyWy3hXS+W9kiAliLRTb+jz8Awd0i77YZ1oQ0 j5PHsS2hUiHA4JL+zkoaB9XIVZJMMOJgG9wE20aPvIpXhwufHmWCZUQACVcitzWZqmVy nPzqcmBzL09gnm/4FIjh4CsdjVBAhYfIB7MhruAfuNNES0uj2EyTk7PF5znhxxrPLXtd qsdZUI/rFnN/PIBoD9gAf2vgIjkQmxie792oC96FH6QkDMH50t+fT07z5BepM9L2SEeg E81w== X-Received: by 10.50.49.78 with SMTP id s14mr2814732ign.62.1369076728076; Mon, 20 May 2013 12:05:28 -0700 (PDT) X-Received: by 10.50.49.78 with SMTP id s14mr2814731ign.62.1369076728010; Mon, 20 May 2013 12:05:28 -0700 (PDT) Received: from x-128-101-233-222.uofm-secure.wireless.umn.edu (x-128-101-233-222.uofm-secure.wireless.umn.edu. [128.101.233.222]) by mx.google.com with ESMTPSA id np6sm1287798igb.0.2013.05.20.12.05.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 12:05:26 -0700 (PDT) Message-ID: <519A73F5.3060307@umn.edu> Date: Mon, 20 May 2013 14:05:25 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jon Mitchell References: <20130520130213.GA17644@puck.nether.net> In-Reply-To: <20130520130213.GA17644@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn66SqXLj+OCjGYniUs0EH6NhwoMC12pWoZbE6wK3rjEDu87fucCPEIzPe0OwR6JS/4ajxcIbFR3f8oC+cJZZT5I4pAHzdStA54Dbdy7qwtt8Yx+0/zx0A2N+ccuv5gk2FmBrgP Cc: idr@ietf.org Subject: Re: [Idr] new draft - reservation of two already reserved ASNs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 19:05:37 -0000 On 5/20/13 08:02 , Jon Mitchell wrote: > > IDR - > > During the private asn draft process, several times it was recommended > that proper documentation of the EXISTING reservations for 65535 and > 4294967295 be done, so have posted a draft to try and rectify that. > Wanted to get some initial feedback on this draft and add any > additional reasoning the group has for these reservations before > asking for WG acceptance. At a minimum, we need to formally document the technical reservation of the numerically highest 16 and 32 bit ASNs as this draft does. However, another approach would be to deal with these two ASNs as a protocol issue and require implementations of BGP to NOT originate or propagate a route with these two ASNs, similar to draft-ietf-idr-as0, section 2 "Behavior". While I'm not convinced this is absolutely necessary, we should strongly consider it. This has the advantage of clearly making any use of these two ASNs an actual protocol error. As drafted, what implementations should do when these two ASNs are seen is ambiguous. I'm afraid some implementations will treat it as an error and others will not, minimally leading interesting operational situations, and worst case leading to outright incompatibilities. On the other hand, treating it only as an operational issue keeps the status quo, and should not require any changes in the BGP protocol. But, if not explicitly disallowed, it should be clear that all implementations must at least provide an option to allow the use of these two ASNs, though. Does anyone know if any implementations disallow the use of one or both of these ASNs currently or maybe planed as part of implementing draft-ietf-idr-as0? Either as the Local ASN, a Neighbor ASN, or within the AS_PATH (or AS4_PATH as appropriate)? Also, someone with a better understanding of RPKI should consider if there are RPKI issues that should be discussed for these two ASNs, I don't think so, but I'm not an expert on RPKI. Thanks for kicking off the discussion with the draft. -- ================================================ 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 jared@puck.nether.net Mon May 20 12:32:59 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E91321F96BA for ; Mon, 20 May 2013 12:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jGoGpct9Vqy for ; Mon, 20 May 2013 12:32:57 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id CF5D221F96A6 for ; Mon, 20 May 2013 12:32:56 -0700 (PDT) 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 r4KJWq9O029676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 15:32:53 -0400 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <519A73F5.3060307@umn.edu> Date: Mon, 20 May 2013 15:32:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130520130213.GA17644@puck.nether.net> <519A73F5.3060307@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (puck.nether.net [204.42.254.5]); Mon, 20 May 2013 15:32:53 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new draft - reservation of two already reserved ASNs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 19:32:59 -0000 On May 20, 2013, at 3:05 PM, David Farmer wrote: > On 5/20/13 08:02 , Jon Mitchell wrote: >>=20 >> IDR - >>=20 >> During the private asn draft process, several times it was = recommended >> that proper documentation of the EXISTING reservations for 65535 and >> 4294967295 be done, so have posted a draft to try and rectify that. >> Wanted to get some initial feedback on this draft and add any >> additional reasoning the group has for these reservations before >> asking for WG acceptance. >=20 > At a minimum, we need to formally document the technical reservation = of the numerically highest 16 and 32 bit ASNs as this draft does. >=20 > However, another approach would be to deal with these two ASNs as a = protocol issue and require implementations of BGP to NOT originate or = propagate a route with these two ASNs, similar to draft-ietf-idr-as0, = section 2 "Behavior". >=20 > While I'm not convinced this is absolutely necessary, we should = strongly consider it. This has the advantage of clearly making any use = of these two ASNs an actual protocol error. As drafted, what = implementations should do when these two ASNs are seen is ambiguous. I'm = afraid some implementations will treat it as an error and others will = not, minimally leading interesting operational situations, and worst = case leading to outright incompatibilities. >=20 > On the other hand, treating it only as an operational issue keeps the = status quo, and should not require any changes in the BGP protocol. But, = if not explicitly disallowed, it should be clear that all = implementations must at least provide an option to allow the use of = these two ASNs, though. There is some significant brain damage out there in some BGP = implementations. eg: Cisco reserves the MED of 2^32-1 as INVALID = internally and forces anything 2^32-1 to 2^32-2 silently. There is some hidden knob in some IOS versions that allows it to have = 2^32-1 properly and moves that overload elsewhere. - Jared= From jrmitche@puck.nether.net Mon May 20 13:13:33 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C202621F9673 for ; Mon, 20 May 2013 13:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX2R5uVvWVM8 for ; Mon, 20 May 2013 13:13:33 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC3A21F9662 for ; Mon, 20 May 2013 13:13:33 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r4KKDUDY000330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 May 2013 16:13:30 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r4KKDUdX000329; Mon, 20 May 2013 16:13:30 -0400 Date: Mon, 20 May 2013 16:13:30 -0400 From: Jon Mitchell To: David Farmer Message-ID: <20130520201329.GA31619@puck.nether.net> References: <20130520130213.GA17644@puck.nether.net> <519A73F5.3060307@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519A73F5.3060307@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (puck.nether.net [127.0.0.1]); Mon, 20 May 2013 16:13:30 -0400 (EDT) Cc: idr@ietf.org Subject: Re: [Idr] new draft - reservation of two already reserved ASNs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:13:33 -0000 On 20/05/13 14:05 -0500, David Farmer wrote: > > Does anyone know if any implementations disallow the use of one or > both of these ASNs currently or maybe planed as part of implementing > draft-ietf-idr-as0? Either as the Local ASN, a Neighbor ASN, or > within the AS_PATH (or AS4_PATH as appropriate)? I don't know of any implementations that don't support these ASN's as normal ASN's today (assuming they have 4 byte AS Support for the 2nd one). I think by any reading of existing standards, having limitations on these ASN's today would be considered a bug. I know a number of networks have used 65535 (it occasionally is leaked as well by folks who don't properly strip private asns) as if it was a Private Use ASN and many vendors documentation include it in the Private Use range regardless of the IANA actual allocation. I'm open to others thoughts, but forcing a change on existing implementations (versus just IETF/operator guidance on ASN's usage) was not my intention. Cheers, Jon From kaliraj@juniper.net Tue May 21 00:33:20 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A497621F9748 for ; Tue, 21 May 2013 00:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y20YEQCpWd1Z for ; Tue, 21 May 2013 00:33:13 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 950AA21F9744 for ; Tue, 21 May 2013 00:33:13 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUZsjOTnFLZR1ZOeiFpq82/twZ6Y5FPzI@postini.com; Tue, 21 May 2013 00:33:13 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 May 2013 00:29:31 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 21 May 2013 00:29:31 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 May 2013 00:40:13 -0700 Received: from mail104-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 07:29:23 +0000 Received: from mail104-ch1 (localhost [127.0.0.1]) by mail104-ch1-R.bigfish.com (Postfix) with ESMTP id 3D99E2E0249 for ; Tue, 21 May 2013 07:29:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail104-ch1 (localhost.localdomain [127.0.0.1]) by mail104-ch1 (MessageSwitch) id 1369121361856963_1850; Tue, 21 May 2013 07:29:21 +0000 (UTC) Received: from CH1EHSMHS014.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail104-ch1.bigfish.com (Postfix) with ESMTP id C53172C0059 for ; Tue, 21 May 2013 07:29:21 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS014.bigfish.com (10.43.70.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 07:29:21 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0311.000; Tue, 21 May 2013 07:29:20 +0000 From: Kaliraj Vairavakkalai To: John Scudder , idr wg Thread-Topic: [Idr] Discussion questions for draft-hares-idr-update-attrib-low-bits-fix-01 Thread-Index: AQHOIalAGHqdJ2183kmgOahJdGG3ApkPoMOA Date: Tue, 21 May 2013 07:29:20 +0000 Message-ID: <4A9FDBF2D3EC984397454CE6161F796A1D56F277@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <9998_1363371364_51436564_9998_4528_1_53C29892C857584299CBF5D05346208A169329@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <9998_1363371364_51436564_9998_4528_1_53C29892C857584299CBF5D05346208A169329@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [Idr] Discussion questions for draft-hares-idr-update-attrib-low-bits-fix-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 07:33:20 -0000 > Q: Does the WG agree? In particular, if you don't agree, please speak up. I tend to agree with the draft's -00 version.=20 Corrected Text: The lower-order four bits of the Attribute Flags octet are unused. They MUST be zero when originated. When received, any value MUST be accepted. When a BGP speaker propagates an attribute, it MUST propagate these flags as received. I don't agree with the draft's -01 version for the following reasons:=20 1. I don't see why it is considered more pragmatic/easier to be able to upg= rade all the "propagating-routers" and "receiving-routers" with this draft-= 01 text, rather than upgrade just the "receiving-routers" with the right be= havior (accept/ignore wrong bits) mentioned in draft-00 version? 2. the -01 version approach basically presumes that the Reserved bits won't= /can't be used in future, so why bother. With this presumption, the -01 app= roach appears to be OK. But for genuine/regular reserved-fields, -00 behavi= or is the right approach. IOW, IMHO, Reserved-fields used else-where (other= protocols, other BGP PDUs) should not follow as example, the direction thi= s draft-01 version is taking. i.e. we may be at risk of setting a wrong exa= mple of "how to handle reserved flag/fields while propagating them" 3. Upgrading the "receiving-routers" to a s/w-version with the right behavi= or(draft-00) - this is a "necessary and sufficient" step to fix this proble= m. And this step is required irrespective of whether we follow draft-00 or = -01 version.=20 Upgrading the "propagating-routers" to a s/w-version with draft-01 behav= ior - this appears to be an extraneous step, and causes the confusion menti= oned in 2 above. So not required, IMHO.=20 Thanks Kaliraj From internet-drafts@ietf.org Tue May 21 01:43:02 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D90021F9784; Tue, 21 May 2013 01:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj8UtdRWCAY2; Tue, 21 May 2013 01:43:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E75921F90BB; Tue, 21 May 2013 01:43:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130521084248.7361.40006.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2013 01:42:48 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-reserved-extended-communities-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 08:43:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Assigned BGP extended communities Author(s) : Bruno Decraene Pierre Francois Filename : draft-ietf-idr-reserved-extended-communities-05.txt Pages : 6 Date : 2013-05-21 Abstract: This document defines an IANA registry in order to assign non- transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide a control over inter-AS community advertisement as, per RFC RFC 4360, they are not transitive across Autonomous System boundaries. For that purpose, this document defines the use of the reserved Autonomous System number 0.65535 in the non-transitive generic four- octet AS specific extended community type. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-reserved-extended-communiti= es There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-reserved-extended-communities-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-reserved-extended-communi= ties-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue May 21 02:41:48 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F8321F9804; Tue, 21 May 2013 02:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HCKORtmvfml; Tue, 21 May 2013 02:41:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF09A21F97F0; Tue, 21 May 2013 02:41:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130521094147.13514.21033.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2013 02:41:47 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 09:41:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : North-Bound Distribution of Link-State and TE Informatio= n using BGP Author(s) : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Saikat Ray Filename : draft-ietf-idr-ls-distribution-03.txt Pages : 43 Date : 2013-05-21 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-ls-distribution-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Donald.Smith@CenturyLink.com Tue May 21 07:57:21 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE4F21F9842 for ; Tue, 21 May 2013 07:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmRYv6uC6vJO for ; Tue, 21 May 2013 07:57:16 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id E2ACC21F983E for ; Tue, 21 May 2013 07:57:15 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r4LEvEkH006698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 08:57:15 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 7AA601E0059; Tue, 21 May 2013 09:57:09 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 5A2951E0066; Tue, 21 May 2013 09:57:09 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r4LEv8X4021295; Tue, 21 May 2013 09:57:08 -0500 (CDT) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.qintra.com [151.119.128.28]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r4LEv8dO021274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 09:57:08 -0500 (CDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.02.0318.001; Tue, 21 May 2013 08:57:08 -0600 From: "Smith, Donald" To: Kaliraj Vairavakkalai , John Scudder , idr wg Thread-Topic: [Idr] Discussion questions for draft-hares-idr-update-attrib-low-bits-fix-01 Thread-Index: AQHOVfV7LbKlDYT1wkCDJEUs+RjpPZkPtFZD Date: Tue, 21 May 2013 14:57:07 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A347716@PDDCWMBXEX503.ctl.intranet> References: <9998_1363371364_51436564_9998_4528_1_53C29892C857584299CBF5D05346208A169329@PEXCVZYM11.corporate.adroot.infra.ftgroup>, <4A9FDBF2D3EC984397454CE6161F796A1D56F277@BL2PRD0510MB349.namprd05.prod.outlook.com> In-Reply-To: <4A9FDBF2D3EC984397454CE6161F796A1D56F277@BL2PRD0510MB349.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.34] Content-Type: multipart/alternative; boundary="_000_68EFACB32CF4464298EA2779B058889D0A347716PDDCWMBXEX503ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Idr] Discussion questions for draft-hares-idr-update-attrib-low-bits-fix-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:57:21 -0000 --_000_68EFACB32CF4464298EA2779B058889D0A347716PDDCWMBXEX503ct_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Because some vendors interpreted what to do when receiving low bits that ar= e set differently the ability to filter those bits on propagating routers i= s a requirement. Does that mean we would filter forever? No. But until we k= now what would happens to routers and their peering connections on receipt = we would filter (remove any announcement with the low order bits set). There are at least 3 major vendors that all interpreted (ignore/accept) dif= ferently. Some drop the peer, others clear the bits automatically before propagating = the announcement, others can if configured for it clear the bits before pro= pagating or propagate them! (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com ________________________________ From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Kaliraj Vair= avakkalai [kaliraj@juniper.net] Sent: Tuesday, May 21, 2013 1:29 AM To: John Scudder; idr wg Subject: Re: [Idr] Discussion questions for draft-hares-idr-update-attrib-l= ow-bits-fix-01 > Q: Does the WG agree? In particular, if you don't agree, please speak up. I tend to agree with the draft's -00 version. Corrected Text: The lower-order four bits of the Attribute Flags octet are unused. They MUST be zero when originated. When received, any value MUST be accepted. When a BGP speaker propagates an attribute, it MUST propagate these flags as received. I don't agree with the draft's -01 version for the following reasons: 1. I don't see why it is considered more pragmatic/easier to be able to upg= rade all the "propagating-routers" and "receiving-routers" with this draft-= 01 text, rather than upgrade just the "receiving-routers" with the right be= havior (accept/ignore wrong bits) mentioned in draft-00 version? 2. the -01 version approach basically presumes that the Reserved bits won't= /can't be used in future, so why bother. With this presumption, the -01 app= roach appears to be OK. But for genuine/regular reserved-fields, -00 behavi= or is the right approach. IOW, IMHO, Reserved-fields used else-where (other= protocols, other BGP PDUs) should not follow as example, the direction thi= s draft-01 version is taking. i.e. we may be at risk of setting a wrong exa= mple of "how to handle reserved flag/fields while propagating them" 3. Upgrading the "receiving-routers" to a s/w-version with the right behavi= or(draft-00) - this is a "necessary and sufficient" step to fix this proble= m. And this step is required irrespective of whether we follow draft-00 or = -01 version. Upgrading the "propagating-routers" to a s/w-version with draft-01 behav= ior - this appears to be an extraneous step, and causes the confusion menti= oned in 2 above. So not required, IMHO. Thanks Kaliraj _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_68EFACB32CF4464298EA2779B058889D0A347716PDDCWMBXEX503ct_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Because some vendors interpreted what to do when receiving low bits that= are set differently the ability to filter those bits on propagating router= s is a requirement. Does that mean we would filter forever? No. But until w= e know what would happens to routers and their peering connections on receipt we would filter (remove any annou= ncement with the low order bits set).

 

There are at least 3 major vendors that all interpreted (ignore/acc= ept) differently.

Some drop the peer, others clear the bits automatically before propagati= ng the announcement, others can if configured for it clear the bits before = propagating or propagate them!

 

 

(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centuryl= ink.com
From: idr-bounces@ietf.org [idr-bounces@ie= tf.org] on behalf of Kaliraj Vairavakkalai [kaliraj@juniper.net]
Sent: Tuesday, May 21, 2013 1:29 AM
To: John Scudder; idr wg
Subject: Re: [Idr] Discussion questions for draft-hares-idr-update-a= ttrib-low-bits-fix-01

> Q: Does the WG agree? In particular, if you d= on't agree, please speak up.

I tend to agree with the draft's -00 version.

           Corrected Text= :

           The lower-orde= r four bits of the Attribute Flags octet are
           unused.  = They MUST be zero when originated.  When received, any
           value MUST be = accepted.  When a BGP speaker propagates an
           attribute, it = MUST propagate these flags as received.

I don't agree with the draft's -01 version for the following reasons:

1. I don't see why it is considered more pragmatic/easier to be able to upg= rade all the "propagating-routers" and "receiving-routers&qu= ot; with this draft-01 text, rather than upgrade just the "receiving-r= outers" with the right behavior (accept/ignore wrong bits) mentioned in draft-00 version?

2. the -01 version approach basically presumes that the Reserved bits won't= /can't be used in future, so why bother. With this presumption, the -01 app= roach appears to be OK. But for genuine/regular reserved-fields, -00 behavi= or is the right approach. IOW, IMHO, Reserved-fields used else-where (other protocols, other BGP PDUs) should n= ot follow as example, the direction this draft-01 version is taking. i.e. w= e may be at risk of setting a wrong example of "how to handle reserved= flag/fields while propagating them"

3. Upgrading the "receiving-routers" to a s/w-version with the ri= ght behavior(draft-00) - this is a "necessary and sufficient" ste= p to fix this problem. And this step is required irrespective of whether we= follow draft-00 or -01 version.
   Upgrading the "propagating-routers" to a s/w-version= with draft-01 behavior - this appears to be an extraneous step, and causes= the confusion mentioned in 2 above. So not required, IMHO.

Thanks
Kaliraj

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
--_000_68EFACB32CF4464298EA2779B058889D0A347716PDDCWMBXEX503ct_-- From kaliraj@juniper.net Wed May 22 10:27:35 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5703621F96F5 for ; Wed, 22 May 2013 10:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzKrBpgsjsW1 for ; Wed, 22 May 2013 10:27:28 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAB021F9410 for ; Wed, 22 May 2013 10:27:22 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUZz/+qLtxUb4P1jynX6UrdKZ/lNIx/OY@postini.com; Wed, 22 May 2013 10:27:22 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 May 2013 10:18:33 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 22 May 2013 10:18:33 -0700 Received: from TX2EHSOBE010.bigfish.com (65.55.88.15) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 22 May 2013 10:22:13 -0700 Received: from mail218-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 22 May 2013 17:18:32 +0000 Received: from mail218-tx2 (localhost [127.0.0.1]) by mail218-tx2-R.bigfish.com (Postfix) with ESMTP id 3800440216 for ; Wed, 22 May 2013 17:18:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1155h) Received: from mail218-tx2 (localhost.localdomain [127.0.0.1]) by mail218-tx2 (MessageSwitch) id 1369243109350488_28466; Wed, 22 May 2013 17:18:29 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.226]) by mail218-tx2.bigfish.com (Postfix) with ESMTP id 499999400C8; Wed, 22 May 2013 17:18:29 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 22 May 2013 17:18:26 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.63]) by BL2PRD0510HT002.namprd05.prod.outlook.com ([10.255.100.37]) with mapi id 14.16.0311.000; Wed, 22 May 2013 17:18:25 +0000 From: Kaliraj Vairavakkalai To: "Smith, Donald" , John Scudder , idr wg Thread-Topic: [Idr] Discussion questions for draft-hares-idr-update-attrib-low-bits-fix-01 Thread-Index: AQHOVjOAuhNZgxDLsEOMV6ZsyxWBapkRb8Hg Date: Wed, 22 May 2013 17:18:24 +0000 Message-ID: <4A9FDBF2D3EC984397454CE6161F796A1D5719D6@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <9998_1363371364_51436564_9998_4528_1_53C29892C857584299CBF5D05346208A169329@PEXCVZYM11.corporate.adroot.infra.ftgroup>, <4A9FDBF2D3EC984397454CE6161F796A1D56F277@BL2PRD0510MB349.namprd05.prod.outlook.com> <68EFACB32CF4464298EA2779B058889D0A347716@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D0A347716@PDDCWMBXEX503.ctl.intranet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.52] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CENTURYLINK.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [Idr] Discussion questions for draft-hares-idr-update-attrib-low-bits-fix-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:27:35 -0000 >Because some vendors interpreted what to do when receiving low bits that a= re set differently the ability to filter those bits on propagating routers = is a requirement.=20 IMHO, Because some vendors interpreted what to do when receiving low bits t= hat are set differently, fixing the vendor software is the requirement.=20 >Does that mean we would filter forever? No. But until we know what would h= appens to routers and their peering connections on=20 >receipt we would filter (remove any announcement with the low order bits s= et). I don't see why protocol-spec (for propagating-routers) should change, that= too "temporarily", until a vendor-software comes up with a bug-fix (for re= ceiving-router role).=A0IMHO, this is unnecessary churn and confusion (ref:= point 2 in my previous mail about risk of setting wrong example) in the st= andards space. Also, I see the use of "ability to filter" in your above statements suggest= s it is optional, i.e. not a MUST, unlike what is stated in the -01 text; v= iz. "They MUST be zero when originated or sent".=20 > There are at least=A03 major vendors that all interpreted (ignore/accept)= differently. > Some drop the peer, others clear the bits automatically before propagatin= g the announcement, others can if configured for it clear the bits before p= ropagating or propagate them! =A0 I fully agree the text should be clarified, as in -00 version of this draft= .=20 =A0 Thanks Kaliraj From jhaas@slice.pfrc.org Wed May 22 10:28:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FABC21F96FE for ; Wed, 22 May 2013 10:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZY0BFln-6mZ for ; Wed, 22 May 2013 10:28:13 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2858F21F9410 for ; Wed, 22 May 2013 10:28:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BF09DC3E0; Wed, 22 May 2013 13:28:12 -0400 (EDT) Date: Wed, 22 May 2013 13:28:12 -0400 From: Jeffrey Haas To: David Farmer Message-ID: <20130522172812.GA10807@pfrc> References: <20130520130213.GA17644@puck.nether.net> <519A73F5.3060307@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519A73F5.3060307@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org Subject: Re: [Idr] new draft - reservation of two already reserved ASNs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:28:18 -0000 David, On Mon, May 20, 2013 at 02:05:25PM -0500, David Farmer wrote: > However, another approach would be to deal with these two ASNs as a > protocol issue and require implementations of BGP to NOT originate > or propagate a route with these two ASNs, similar to > draft-ietf-idr-as0, section 2 "Behavior". > > While I'm not convinced this is absolutely necessary, we should > strongly consider it. This has the advantage of clearly making any > use of these two ASNs an actual protocol error. As drafted, what > implementations should do when these two ASNs are seen is ambiguous. > I'm afraid some implementations will treat it as an error and others > will not, minimally leading interesting operational situations, and > worst case leading to outright incompatibilities. I believe that with 65535 we're already in this situation to some extent. I believe many implementations will treat it as being in the "private" range and thus subject to "remove-private" and similar knobs. Similarly, a lot of people's AS-path filters are likely to include this from common operational practice. IMO, permitting this AS to be used as private, despite not being included as such, is probably okay. Where things get messy is where pedantic BGP implementations may choose to not consider it private where others do and thus we end up with inconsistent behaviors. AS 2^32-1 doesn't currently have such history and I'm less concerned here. This perhaps opens the question of whether we should simply give up on 65535, remand it to the private AS range and if that doesn't happen to work between a given set of providers, consider it an implementation issue? -- Jeff From internet-drafts@ietf.org Thu May 23 08:37:41 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9DF21F9725; Thu, 23 May 2013 08:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93xvaBjrQoUG; Thu, 23 May 2013 08:37:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0757021F96C8; Thu, 23 May 2013 08:37:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523153740.24347.1093.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 08:37:40 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aigp-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:37:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : The Accumulated IGP Metric Attribute for BGP Author(s) : Pradosh Mohapatra Rex Fernando Eric C. Rosen James Uttaro Filename : draft-ietf-idr-aigp-10.txt Pages : 14 Date : 2013-05-23 Abstract: Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-aigp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-aigp-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-aigp-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shares@ndzh.com Fri May 24 14:26:17 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D1211E8112 for ; Fri, 24 May 2013 14:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.55 X-Spam-Level: ** X-Spam-Status: No, score=2.55 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGbGdG1LbAp6 for ; Fri, 24 May 2013 14:26:12 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 62CA311E8105 for ; Fri, 24 May 2013 14:26:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.173.42; From: "Susan Hares" To: Date: Fri, 24 May 2013 17:26:04 -0400 Message-ID: <000601ce58c5$4c0f0f20$e42d2d60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CE58A3.C4FF1CD0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac5Yw6gsH8UT/KWHQnmqm2uL1fZlvg== X-Authenticated-User: skh@ndzh.com Subject: [Idr] FYI - Sue Hares company change X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 21:26:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0007_01CE58A3.C4FF1CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: Our Area-Directors have encouraged me to share my job change information to provide transparency on my IETF work. I am currently working at Adara Networks, an SDN/Cloud company. This company is supporting my IETF work. The Adara Networks code base includes BGP. If you have questions about my current company and its interaction with SDN work, please send me a questions to my company email or my standard email (shares@ndzh.com). Sue Hares VP, Technology and Strategy Adara Networks shares@adaranet.com shares@ndzh.com ------=_NextPart_000_0007_01CE58A3.C4FF1CD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all:

 

Our Area-Directors have encouraged me to share my job = change information to provide transparency on my IETF work.  I am = currently working at Adara Networks, an SDN/Cloud company.  This = company is supporting my IETF work.  

 

The Adara = Networks code base includes BGP.   If you have questions about = my current company and its interaction with SDN work, please send me a = questions to my company email or my standard email (shares@ndzh.com).

 

Sue Hares =

VP, Technology and = Strategy

Adara = Networks

shares@adaranet.com

shares@ndzh.com =  

------=_NextPart_000_0007_01CE58A3.C4FF1CD0-- From internet-drafts@ietf.org Wed May 29 08:26:47 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9322821F8E9D; Wed, 29 May 2013 08:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf4pTyU-C4Bs; Wed, 29 May 2013 08:26:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EED121F944C; Wed, 29 May 2013 08:26:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130529152640.26629.49265.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2013 08:26:40 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-private-reservation-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 15:26:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Autonomous System (AS) Reservation for Private Use Author(s) : Jon Mitchell Filename : draft-ietf-idr-as-private-reservation-05.txt Pages : 4 Date : 2013-05-29 Abstract: This document describes the reservation of Autonomous System numbers (ASNs) that are for Private Use only and MUST NOT be advertised to the Internet, known as Private Use ASNs. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-as-private-reservation-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jgs@juniper.net Wed May 29 12:17:52 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E8221F97B3 for ; Wed, 29 May 2013 12:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ4OrlqgTxvp for ; Wed, 29 May 2013 12:17:45 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE0421F97D5 for ; Wed, 29 May 2013 12:17:31 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUaZUSucn+NJiSnAafHG6Gy/EY8ZTFO/t@postini.com; Wed, 29 May 2013 12:17:31 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 29 May 2013 12:15:09 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 29 May 2013 12:15:08 -0700 Received: from CO9EHSOBE002.bigfish.com (207.46.163.24) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 29 May 2013 12:18:31 -0700 Received: from mail25-co9-R.bigfish.com (10.236.132.246) by CO9EHSOBE002.bigfish.com (10.236.130.65) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 May 2013 19:15:08 +0000 Received: from mail25-co9 (localhost [127.0.0.1]) by mail25-co9-R.bigfish.com (Postfix) with ESMTP id 1857FB8048D for ; Wed, 29 May 2013 19:15:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 2 X-BigFish: PS2(zzda00h4015Idc73hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1082kzzz31h2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1155h) Received-SPF: softfail (mail25-co9: transitioning domain of juniper.net does not designate 132.245.2.21 as permitted sender) client-ip=132.245.2.21; envelope-from=jgs@juniper.net; helo=BN1PRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail25-co9 (localhost.localdomain [127.0.0.1]) by mail25-co9 (MessageSwitch) id 1369854852770145_15031; Wed, 29 May 2013 19:14:12 +0000 (UTC) Received: from CO9EHSMHS017.bigfish.com (unknown [10.236.132.254]) by mail25-co9.bigfish.com (Postfix) with ESMTP id AE1E05C007B for ; Wed, 29 May 2013 19:13:58 +0000 (UTC) Received: from BN1PRD0512HT002.namprd05.prod.outlook.com (132.245.2.21) by CO9EHSMHS017.bigfish.com (10.236.130.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 May 2013 19:13:56 +0000 Received: from jmccombe-sslvpn-nc.jnpr.net (66.129.232.2) by pod51010.outlook.com (10.255.193.35) with Microsoft SMTP Server (TLS) id 14.16.311.1; Wed, 29 May 2013 19:13:50 +0000 From: John Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <270F05D9-B79B-41D1-B63D-B6EB5235167B@juniper.net> Date: Wed, 29 May 2013 15:13:47 -0400 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Originating-IP: [66.129.232.2] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Idr] WG adoption requested for draft-jhjm-idr-last-as-reservations-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 19:17:53 -0000 Folks, The authors have requested IDR adopt = draft-jhjm-idr-last-as-reservations-00 as a working group document. Please send any comments to the list by June 13. Thanks, --John From erosen@cisco.com Fri May 31 08:47:45 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EB421F8E9D for ; Fri, 31 May 2013 08:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1Agkg-Q0-Mg for ; Fri, 31 May 2013 08:47:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6834421F8E93 for ; Fri, 31 May 2013 08:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6991; q=dns/txt; s=iport; t=1370015260; x=1371224860; h=from:to:subject:mime-version:date:message-id; bh=sA7VZfoNzVmkFl++7tFRECtY8mz654lIUvwQ2LJ7WME=; b=Y5fQ8RzDlbcZhNG6z1U0+HX+0Duo4SQkC8kfCVqcVPiT4vo4GBEjd9h7 SQJ/ZS0H3QCV61I96cefWXHuv4neYf9vekAuCOQASZN6chx548jmBG8c8 ha4/ghpFd0G4eeS+GWfx7XEuuZmteQHbjdn81CHhwbGXG9OauHMXwLGxL Y=; X-Files: : None X-IronPort-AV: E=Sophos;i="4.87,779,1363132800"; d="scan'208";a="217348281" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 31 May 2013 15:47:40 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4VFldL3027091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 15:47:39 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r4VFlc3I010032; Fri, 31 May 2013 11:47:38 -0400 From: Eric Rosen To: IDR WG X-Mailer: MH-E 8.3.1; nmh 1.5; GNU Emacs 24.3.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Fri, 31 May 2013 11:47:38 -0400 Message-ID: <10031.1370015258@erosen-linux> Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 15:47:45 -0000 --=-=-= Content-Type: text/plain I would like to call this draft to the attention of the WG. This draft proposes to reorganize the IANA registries for BGP Extended Communities, so that there are separate registries for types and sub-types, and so that the values that are available for assignment in one registry do not depend upon the values that have already been assigned in another. Yakov and I put this proposal together after hearing some complaints from IANA about the difficulty of figuring out which values are available in which registries. We also found some mistakes in the registries and some inconsistencies in the drafts that define the registries. The intention of this draft is to make it easier for IANA to fulfill its clerical function, and to make it easier to understand what to request of IANA when a new Extended Community is defined. No changes to existing implementations or deployments are required. If you care about this sort of stuff, please review and provide your comments. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=3423 Content-Description: forwarded message MIME-Version: 1.0 Received: from mail.cisco.com [173.37.183.72] by erosen-linux with IMAP (fetchmail-6.3.6) for (single-drop); Thu, 30 May 2013 13:51:50 -0400 (EDT) Received: from rcdn-iport-3.cisco.com (173.37.86.74) by mail.cisco.com (173.36.12.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 30 May 2013 12:51:06 -0500 Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 30 May 2013 17:51:06 +0000 Received: from rcdn-inbound-h.cisco.com (rcdn-inbound-h.cisco.com [72.163.7.177]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4UHp50T018972; Thu, 30 May 2013 17:51:05 GMT Authentication-Results: rcdn-inbound-h.cisco.com; dkim=pass (signature verified [TEST]) header.i=@ietf.org X-from-outside-Cisco: 12.22.58.30 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwBAMCQp1EMFjoenGdsb2JhbABZgmhRjG22JxYOAQEBAQEGDQkJFCiCJQEBBAEBNwYBAQQKHgwCAwECBgJACAgDASNJBQSIBQIJqFCEPgEFjkoGjzmDQYkjik2DUAGBKYp3hEKEDQ X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="108541937" Received: from mail.ietf.org ([12.22.58.30]) by rcdn-inbound-h.cisco.com with ESMTP; 30 May 2013 17:51:02 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2E521F968F; Thu, 30 May 2013 10:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1369936254; bh=f9K8hgMBlrC6IvJlZGQ7gsMdJ1y8H9QLf1OKoW85G7s=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=OVexJgUO33kxYqNt/rg6+OrLmO1a2+GxCT13wCvsmy3Pm41a2DfP7BKhFbwdocfzE PGEjASzZW82rK5JwD/dI59+Byy9b13OLAN/U6q48AApj52j4T0/LrM22gJw89RXKcc llbJsjQFt0J6nZEn99e+BEszFZa7emUMWv8s2npY= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7792021F968D for ; Thu, 30 May 2013 10:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1yYnbYGT9sp for ; Thu, 30 May 2013 10:50:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9AE21F9413 for ; Thu, 30 May 2013 10:50:46 -0700 (PDT) From: To: Subject: I-D Action: draft-rosen-idr-extcomm-iana-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130530175046.32443.80430.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2013 10:50:46 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: i-d-announce-bounces@ietf.org Return-Path: i-d-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: xhc-aln-x05.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Registries for BGP Extended Communities Author(s) : Eric C. Rosen Yakov Rekhter Filename : draft-rosen-idr-extcomm-iana-00.txt Pages : 17 Date : 2013-05-30 Abstract: This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove inter-dependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations, and thus do not affect protocol implementations. The changes will however impact the "IANA Considerations" sections of future protocol specifications. This document updates RFCs 4360 and 5701. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rosen-idr-extcomm-iana There's also a htmlized version available at: http://tools.ietf.org/html/draft-rosen-idr-extcomm-iana-00 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 --=-=-=--