From iesg-secretary@ietf.org Mon Jun 3 12:33: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 27B7C21F8F4D; Mon, 3 Jun 2013 12:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.179, 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 Hn3JL74KMCBi; Mon, 3 Jun 2013 12:33:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB6221F9452; Mon, 3 Jun 2013 12:27:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603192700.17619.5447.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 12:27:00 -0700 Cc: idr mailing list , idr chair , RFC Editor Subject: [Idr] Protocol Action: 'Autonomous System (AS) Reservation for Private Use' to Best Current Practice (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: Mon, 03 Jun 2013 19:33:52 -0000 The IESG has approved the following document: - 'Autonomous System (AS) Reservation for Private Use' (draft-ietf-idr-as-private-reservation-05.txt) as Best Current Practice 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-as-private-reservation/ Technical Summary 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. Working Group Summary Working group: WG list had 2 rounds of WG LC - one for approval of draft and one for actual range size. The majority view in the WG is that it fixes a clear operational problem in the reasonable use of private AS numbers. The minority view is that all AS numbers should be registered. The chairs anticipated this operational debate would continue during IETF last call. This issue was raised directly with the IESG and the AD worked with the authors and chairs to remove the justification text that appeared to be causing concern, i.e. without loosing the generality of the expanded AS range to focus the need to do this on the new applications such as DC which the reviewer noted justifies the change in its own right. Document Quality Large DC providers (Microsoft (author)) and cloud providers have requested to aid ral operational usage. This is range BCP. IANA registry need to be informed. Careful review by both WG chairs (one serving as Shepherd). Personnel Document shepherd: Susan Hares AD: Stewart Bryant. From farmer@umn.edu Mon Jun 3 23:08:46 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648B521F9AD0 for ; Mon, 3 Jun 2013 23:08:46 -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 BHccSU7fvarN for ; Mon, 3 Jun 2013 23:08:29 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 46C3221E8142 for ; Mon, 3 Jun 2013 22:02:02 -0700 (PDT) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 4 Jun 2013 00:01:54 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f181.google.com [209.85.223.181] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f181.google.com with SMTP id x14so12381977ief.26 for ; Mon, 03 Jun 2013 22:01:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=ss0PpNQl18j+6PBIH9S+sqSuBakW5w55LL7qaED3gRM=; b=L7XUfigm1W/WzN3KSutDtBe4OEvbA3KCuQNaoF/tWZNTQb7XF3qiXhGs+zj3KRwts/ 5oswWwDkVXgwqYnXndRW3nslWHTH/uD2nseF2IBgYJkqtrLzZWf1KQ+HaQXgDRt7Skcu OkWA+rg+bIPubgSMFOqe4I9LJtyTfuP4O6aSFGmbZ1fYizc/sM7dHrjLCOLPWgup8nM6 Ykl06F1/3yWIt6+TOkkOVMqLXDU2THr2onAUH7G+JgNzfpgwBiNx8ePH99BMz5SR2lHU 99NN30Z0vDL9V/T/4VPOh4QfxU24LFLMbfNEpyKHfiV0m7nFJGdWhuQVNVVjJ3xObNUs L5VA== X-Received: by 10.42.87.144 with SMTP id y16mr11755113icl.46.1370322114710; Mon, 03 Jun 2013 22:01:54 -0700 (PDT) X-Received: by 10.42.87.144 with SMTP id y16mr11755110icl.46.1370322114619; Mon, 03 Jun 2013 22:01:54 -0700 (PDT) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPSA id ik6sm54407igb.3.2013.06.03.22.01.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 22:01:53 -0700 (PDT) Message-ID: <51AD74C1.4030601@umn.edu> Date: Tue, 04 Jun 2013 00:01:53 -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: John Scudder References: <270F05D9-B79B-41D1-B63D-B6EB5235167B@juniper.net> In-Reply-To: <270F05D9-B79B-41D1-B63D-B6EB5235167B@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmQtrpr2HlNnD9xvrLOzSK2DOIU8yariY2KR4vrP78vqhzpyCU4s6Cdy7DPMtodpe1eqZZaW66eVz62Y5nGRmDjx/DPCTvYQhl4mRVSukDDyO6F9LuHOjXf9bwTISXw0KKlZy2f Cc: "idr@ietf. org" Subject: Re: [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 Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 06:08:46 -0000 On 5/29/13 14:13 , John Scudder wrote: > 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. Support adoption by the WG. -- ================================================ 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 farmer@umn.edu Tue Jun 4 00:59:09 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28BA21F9B75 for ; Tue, 4 Jun 2013 00:59:09 -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 Fl+POa3h1Cze for ; Tue, 4 Jun 2013 00:58:54 -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 0C74521E8051 for ; Tue, 4 Jun 2013 00:04:21 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 4 Jun 2013 02:04:20 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f179.google.com [209.85.223.179] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f179.google.com with SMTP id c13so1469285ieb.24 for ; Tue, 04 Jun 2013 00:04:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=b64FPtB0WwXROux5/tBXf0WvuFxKeLdrsPTroiDmy74=; b=ANRqMOnr4EhmGe9sJmxLHo9Una3dF8z+L7hSLO310WtUg4zpJ9amftiZVuhJLwWxq5 9qKsWk+hXUpRx5Ovme7pusVwlWSfTg5kCeijronOmNGunViH1Hd2okvzHMQ/RL5eKwVe Qc7R6oEXHDbzF2KacUDzTPiFY1//Zf7dJUhvigxooR/4yEKnLbrLa63lOtA3Jrlx/hR3 BpDNecyaC2Yj7R1U5WfO0iYCPZdbqhi9vuu3hSIEqjm1p8xg3DWEkVZHj1StO9A0ghTm C3fLqOx1AMDeUBgTTKOTtNmOkgiy3qCnPDbDW63I74AC3eegGkm/cUmsOgOt+Jpe6z6g q5ew== X-Received: by 10.50.141.234 with SMTP id rr10mr11386igb.34.1370329460494; Tue, 04 Jun 2013 00:04:20 -0700 (PDT) X-Received: by 10.50.141.234 with SMTP id rr10mr11335igb.34.1370329459167; Tue, 04 Jun 2013 00:04:19 -0700 (PDT) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPSA id f6sm522144igz.1.2013.06.04.00.04.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 00:04:18 -0700 (PDT) Message-ID: <51AD9177.7080206@umn.edu> Date: Tue, 04 Jun 2013 02:04:23 -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> <519A73F5.3060307@umn.edu> <20130520201329.GA31619@puck.nether.net> In-Reply-To: <20130520201329.GA31619@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkF6p4gUtEd46jaug0bNuktLABgvOl8kszMk59ggXg8CF7Qzj5tUaRjz97CJPlbZ3mR09Wf44yyh1T4tj3Er5P7zKpYhcLwXFqPFg+6SaTr7oHgKFyztNZzIy32UJCgFulYrKNA 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: Tue, 04 Jun 2013 07:59:10 -0000 On 5/20/13 15:13 , Jon Mitchell wrote: ... > 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. I'd like to hear others thoughts too. As I said, I'm not certain we need to make this a protocol change, but I would like to hear more opinions on the subject. But for the moment, assuming we don't make this into a protocol change, I have a few comments on the current text. 1. I'd suggest making section 4 exclusively about guidance for operators and splitting the guidance for BGP implementation into a separate section. 2. I'm mostly OK with the operator guidance in the draft, but I think it would be more accurate to change "or for any other purpose" to "and SHOULD NOT use these ASNs for any other purpose, except an otherwise designated Special Use", and the "MAY filter" language I feel needs to stronger, probably "SHOULD filter" would be better. 3. But I think the guidance for BGP implementations needs a lot more work. As I said; "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." Therefore, if use of these ASNs are NOT going to be made a protocol error, then it needs to be made explicit that its NOT a protocol error and all implementations must accept these ASNs. I think the "MAY filter" is appropriate for implementation guidance. Bringing these together and with some other minor changes, here is some suggested text for you, use it as you feel appropriate; 4. Operational Considerations Operators MUST NOT use these Last ASNs as if they are Private Use ASNs, and SHOULD NOT use these reserved ASNs for any other purpose, except an otherwise designated Special Use. Any other operational use of these reserved ASNs could have unpredictable or undesirable results. For example; use of ASN 65535 as if it was a Private Use ASN, may result in inadvertent use of BGP Well-known community values [IANA.WK], causing undesirable routing behavior if prefixes are inadvertently tagged with BGP Well-known communities. Operators that choose to filter Private Use ASNs within the AS_PATH, and AS4_PATH, SHOULD also filter these Last ASNs in the same way, to prevent the use of these reserved ASNs on their networks and the Internet. 5. BGP Implementation Considerations While these Last ASNs are reserved, they are valid ASNs from a protocol perspective. Therefore, implementations MUST NOT treat the use of these ASNs as any type of error. All implementations MUST accept these ASNs as the local AS, or as a peer AS in an OPEN message. However, an implementations MAY generate some kind of warning message indicating possible improper use of a reserved ASN. Implementations that provide tools that filter Private Use ASNs within the AS_PATH, and AS4_PATH, MAY also include these Last ASNs and filter them in the same way as Private Use ASNs. Thanks for working on this. -- ================================================ 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 mohan.nanduri@gmail.com Tue Jun 4 04:51:07 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1770E21F99E3 for ; Tue, 4 Jun 2013 04:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 38G2CNpiueuU for ; Tue, 4 Jun 2013 04:50:54 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B8D2E21F9B32 for ; Tue, 4 Jun 2013 03:32:51 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wy17so38004pbc.37 for ; Tue, 04 Jun 2013 03:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dXeIv5MAN1OdglS+fHT4tk9anl+lQsYl3g2gKeBe7qU=; b=aQhVQ1AEuJ2tTGkIW+/iwYnGGzfdlFRlBJ7zZVKT6y/a+ZUmqxnhcItsiTcglwRfhF We/75Bjw1sGxNsCL/ysAxXInxzNiFS24YVJ2N655lrW2SivqekOGED1Sl2SzerVRw1kJ uuZuHqEwMJdIlDRElQ/I3uKccfzT7HiQ96FWTx+2KxX6vb/dgrJ2Og7fMj7sEj3DIZcb y6wiS0Bg2NtCzJwcbjZT3WHokNgrDR5Y7PjYn702uWMGqJVRggogZvHZlKWS+UlyI6tQ etZ//QFZxs7kQjjytn2ADEUhQMozgGEBd4KzJpRvl3PoJyRQRGePtzh1lLBxETak4Gjf DaGA== MIME-Version: 1.0 X-Received: by 10.66.122.68 with SMTP id lq4mr27991061pab.78.1370341971417; Tue, 04 Jun 2013 03:32:51 -0700 (PDT) Received: by 10.68.143.225 with HTTP; Tue, 4 Jun 2013 03:32:51 -0700 (PDT) In-Reply-To: <51AD74C1.4030601@umn.edu> References: <270F05D9-B79B-41D1-B63D-B6EB5235167B@juniper.net> <51AD74C1.4030601@umn.edu> Date: Tue, 4 Jun 2013 06:32:51 -0400 Message-ID: From: Mohan Nanduri To: David Farmer Content-Type: multipart/alternative; boundary=047d7b2e4bc46e31a804de519a9e Cc: "idr@ietf. org" Subject: Re: [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: Tue, 04 Jun 2013 11:51:07 -0000 --047d7b2e4bc46e31a804de519a9e Content-Type: text/plain; charset=ISO-8859-1 +1 Cheers, -Mohan On Tue, Jun 4, 2013 at 1:01 AM, David Farmer wrote: > On 5/29/13 14:13 , John Scudder wrote: > >> 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. >> > > Support adoption by the WG. > > -- > ==============================**================== > 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 > ==============================**================== > > ______________________________**_________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/**listinfo/idr > --047d7b2e4bc46e31a804de519a9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

Cheers,
-Mohan

=


On Tue,= Jun 4, 2013 at 1:01 AM, David Farmer <farmer@umn.edu> wrote:
On 5/29/13 14:13 , John Sc= udder wrote:
Folks,

The authors have requested IDR adopt draft-jhjm-idr-last-as-reservat= ions-00 as a working group document.

Please send any comments to the list by June 13.

Support adoption by the WG.<= br>
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email: farmer@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE =A0 =A0 Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 =A0Cell: 1-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= =3D

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

--047d7b2e4bc46e31a804de519a9e-- From jared@puck.nether.net Tue Jun 4 08:32: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 6F33821F9A36 for ; Tue, 4 Jun 2013 08:32:18 -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 ETMqV+jT9l23 for ; Tue, 4 Jun 2013 08:32:04 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0914221F9B65 for ; Tue, 4 Jun 2013 06:37:55 -0700 (PDT) Received: from [192.168.6.5] ([64.134.176.255]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r54DbnKh010742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Jun 2013 09:37:50 -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: <51AD9177.7080206@umn.edu> Date: Tue, 4 Jun 2013 09:37:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9362AF6C-9B62-446B-A357-32FF3285CED7@puck.nether.net> References: <20130520130213.GA17644@puck.nether.net> <519A73F5.3060307@umn.edu> <20130520201329.GA31619@puck.nether.net> <51AD9177.7080206@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]); Tue, 04 Jun 2013 09:37:51 -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: Tue, 04 Jun 2013 15:32:18 -0000 I think the text below in 4/5 looks good. - Jared On Jun 4, 2013, at 3:04 AM, David Farmer wrote: > On 5/20/13 15:13 , Jon Mitchell wrote: > ... >> 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. >=20 > I'd like to hear others thoughts too. As I said, I'm not certain we = need to make this a protocol change, but I would like to hear more = opinions on the subject. >=20 > But for the moment, assuming we don't make this into a protocol = change, I have a few comments on the current text. >=20 > 1. I'd suggest making section 4 exclusively about guidance for = operators and splitting the guidance for BGP implementation into a = separate section. >=20 > 2. I'm mostly OK with the operator guidance in the draft, but I think = it would be more accurate to change "or for any other purpose" to "and = SHOULD NOT use these ASNs for any other purpose, except an otherwise = designated Special Use", and the "MAY filter" language I feel needs to = stronger, probably "SHOULD filter" would be better. >=20 > 3. But I think the guidance for BGP implementations needs a lot more = work. As I said; "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." Therefore, if use of these ASNs are NOT going to be = made a protocol error, then it needs to be made explicit that its NOT a = protocol error and all implementations must accept these ASNs. I think = the "MAY filter" is appropriate for implementation guidance. >=20 > Bringing these together and with some other minor changes, here is = some suggested text for you, use it as you feel appropriate; >=20 > 4. Operational Considerations >=20 > Operators MUST NOT use these Last ASNs as if they are Private Use > ASNs, and SHOULD NOT use these reserved ASNs for any other purpose, > except an otherwise designated Special Use. Any other operational > use of these reserved ASNs could have unpredictable or undesirable > results. For example; use of ASN 65535 as if it was a Private Use > ASN, may result in inadvertent use of BGP Well-known community > values [IANA.WK], causing undesirable routing behavior if prefixes > are inadvertently tagged with BGP Well-known communities. >=20 > Operators that choose to filter Private Use ASNs within the > AS_PATH, and AS4_PATH, SHOULD also filter these Last ASNs in the > same way, to prevent the use of these reserved ASNs on their > networks and the Internet. >=20 > 5. BGP Implementation Considerations >=20 > While these Last ASNs are reserved, they are valid ASNs from a > protocol perspective. Therefore, implementations MUST NOT treat > the use of these ASNs as any type of error. All implementations > MUST accept these ASNs as the local AS, or as a peer AS in an OPEN > message. However, an implementations MAY generate some kind of > warning message indicating possible improper use of a reserved ASN. >=20 > Implementations that provide tools that filter Private Use ASNs > within the AS_PATH, and AS4_PATH, MAY also include these Last ASNs > and filter them in the same way as Private Use ASNs. >=20 > Thanks for working on this. >=20 > --=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=3D > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Tue Jun 4 11:27:51 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313BC21F9A40; Tue, 4 Jun 2013 11:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.213, 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 GoxZpk7fwaW2; Tue, 4 Jun 2013 11:27:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B263121F8F29; Tue, 4 Jun 2013 10:51:16 -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: <20130604175116.21732.63883.idtracker@ietfa.amsl.com> Date: Tue, 04 Jun 2013 10:51:16 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-optimal-route-reflection-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, 04 Jun 2013 18:27:51 -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 Optimal Route Reflection (BGP-ORR) Author(s) : Robert Raszuk Christian Cassar Erik Aman Bruno Decraene Stephane Litkowski Filename : draft-ietf-idr-bgp-optimal-route-reflection-05.txt Pages : 22 Date : 2013-06-04 Abstract: [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress point in cases where no higher priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the egress point closest to the route reflector - and not necessarily closest to the RR clients. Section 11 of [RFC4456] describes a deployment approach and a set of constraints which, if satsified, would result in the deployment of route reflection yielding the same results as the iBGP full mesh approach. Such a deployment approach would make route reflection compatible with the application of hot potato routing policy. As networks evolved to accommodate architectural requirements of new services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes two new solutions which can be deployed to facilitate the application of closest exit point policy centralized route reflection deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-optimal-route-reflect= ion-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jrmitche@puck.nether.net Thu Jun 6 17:37: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 A956E21F8AC2 for ; Thu, 6 Jun 2013 17:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYYXDLtPI2Jq for ; Thu, 6 Jun 2013 17:37:02 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1E52521F89A5 for ; Thu, 6 Jun 2013 17:37:02 -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 r570axqa020886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Jun 2013 20:36:59 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r570ax28020885; Thu, 6 Jun 2013 20:36:59 -0400 Date: Thu, 6 Jun 2013 20:36:59 -0400 From: Jon Mitchell To: John Scudder Message-ID: <20130607003658.GA19821@puck.nether.net> References: <270F05D9-B79B-41D1-B63D-B6EB5235167B@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <270F05D9-B79B-41D1-B63D-B6EB5235167B@juniper.net> 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]); Thu, 06 Jun 2013 20:36:59 -0400 (EDT) Cc: "idr@ietf. org" Subject: Re: [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: Fri, 07 Jun 2013 00:37:02 -0000 On 29/05/13 15:13 -0400, John Scudder wrote: > Folks, > > The authors have requested IDR adopt draft-jhjm-idr-last-as-reservations-00 as a working group document. +1 as author Jon From jrmitche@puck.nether.net Thu Jun 6 17:43: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 4E9EC21F9050 for ; Thu, 6 Jun 2013 17:43:32 -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 XzTsxIQ0RhwQ for ; Thu, 6 Jun 2013 17:43:31 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id EDFE921F8616 for ; Thu, 6 Jun 2013 17:43:30 -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 r570hPAW021374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Jun 2013 20:43:25 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r570hPhJ021373; Thu, 6 Jun 2013 20:43:25 -0400 Date: Thu, 6 Jun 2013 20:43:25 -0400 From: Jon Mitchell To: Jared Mauch Message-ID: <20130607004325.GB19821@puck.nether.net> References: <20130520130213.GA17644@puck.nether.net> <519A73F5.3060307@umn.edu> <20130520201329.GA31619@puck.nether.net> <51AD9177.7080206@umn.edu> <9362AF6C-9B62-446B-A357-32FF3285CED7@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9362AF6C-9B62-446B-A357-32FF3285CED7@puck.nether.net> 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]); Thu, 06 Jun 2013 20:43:25 -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: Fri, 07 Jun 2013 00:43:33 -0000 On 04/06/13 09:37 -0400, Jared Mauch wrote: > I think the text below in 4/5 looks good. > > - Jared I'd prefer to work out the specific wording once/if WG agrees to work on this (I'm assuming you support the draft?) but I also generally like the below section 4/5 text suggestions, think splitting the sections is a great idea and think implementations should continue to allow use of these ASNs (not add new code to treat as error). Jon > > On Jun 4, 2013, at 3:04 AM, David Farmer wrote: > > > On 5/20/13 15:13 , Jon Mitchell wrote: > > ... > >> 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. > > > > I'd like to hear others thoughts too. As I said, I'm not certain we need to make this a protocol change, but I would like to hear more opinions on the subject. > > > > But for the moment, assuming we don't make this into a protocol change, I have a few comments on the current text. > > > > 1. I'd suggest making section 4 exclusively about guidance for operators and splitting the guidance for BGP implementation into a separate section. > > > > 2. I'm mostly OK with the operator guidance in the draft, but I think it would be more accurate to change "or for any other purpose" to "and SHOULD NOT use these ASNs for any other purpose, except an otherwise designated Special Use", and the "MAY filter" language I feel needs to stronger, probably "SHOULD filter" would be better. > > > > 3. But I think the guidance for BGP implementations needs a lot more work. As I said; "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." Therefore, if use of these ASNs are NOT going to be made a protocol error, then it needs to be made explicit that its NOT a protocol error and all implementations must accept these ASNs. I think the "MAY filter" is appropriate for implementation guidance. > > > > Bringing these together and with some other minor changes, here is some suggested text for you, use it as you feel appropriate; > > > > 4. Operational Considerations > > > > Operators MUST NOT use these Last ASNs as if they are Private Use > > ASNs, and SHOULD NOT use these reserved ASNs for any other purpose, > > except an otherwise designated Special Use. Any other operational > > use of these reserved ASNs could have unpredictable or undesirable > > results. For example; use of ASN 65535 as if it was a Private Use > > ASN, may result in inadvertent use of BGP Well-known community > > values [IANA.WK], causing undesirable routing behavior if prefixes > > are inadvertently tagged with BGP Well-known communities. > > > > Operators that choose to filter Private Use ASNs within the > > AS_PATH, and AS4_PATH, SHOULD also filter these Last ASNs in the > > same way, to prevent the use of these reserved ASNs on their > > networks and the Internet. > > > > 5. BGP Implementation Considerations > > > > While these Last ASNs are reserved, they are valid ASNs from a > > protocol perspective. Therefore, implementations MUST NOT treat > > the use of these ASNs as any type of error. All implementations > > MUST accept these ASNs as the local AS, or as a peer AS in an OPEN > > message. However, an implementations MAY generate some kind of > > warning message indicating possible improper use of a reserved ASN. > > > > Implementations that provide tools that filter Private Use ASNs > > within the AS_PATH, and AS4_PATH, MAY also include these Last ASNs > > and filter them in the same way as Private Use ASNs. > > > > Thanks for working on this. > > > > -- > > ================================================ > > 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 > > ================================================ > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > From adrian@olddog.co.uk Fri Jun 7 07:31:28 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B3121F9843; Fri, 7 Jun 2013 07:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 WZgvF+m97hSY; Fri, 7 Jun 2013 07:31:23 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2548021F9920; Fri, 7 Jun 2013 07:31:10 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57EV6D2007140; Fri, 7 Jun 2013 15:31:06 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57EV5Kk007127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Jun 2013 15:31:06 +0100 From: "Adrian Farrel" To: , , , , Date: Fri, 7 Jun 2013 15:30:59 +0100 Message-ID: <0afa01ce638b$a2067820$e6136860$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5ji41bX64WTevZT8eVu8We0gvrYQ== Content-Language: en-gb Cc: draft-ietf-ipsecme-ad-vpn-problem.all@tools.ietf.org Subject: [Idr] Heads up : IETF Last Call on "Auto Discovery VPN Problem Statement and Requirements" X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:31:28 -0000 Hi VPN-related working groups, Please be aware of this document that is in IETF last call. Comments should be sent following the instructions in the email below and *not* to the mailing lists I have spammed. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 07 June 2013 15:00 > To: IETF-Announce > Cc: ipsec@ietf.org > Subject: Last Call: (Auto Discovery > VPN Problem Statement and Requirements) to Informational RFC > > > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > - 'Auto Discovery VPN Problem Statement and Requirements' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-06-21. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes the problem of enabling a large number of > systems to communicate directly using IPsec to protect the traffic > between them. It then expands on the requirements, for such a > solution. > > Manual configuration of all possible tunnels is too cumbersome in > many such cases. In other cases the IP address of endpoints change > or the endpoints may be behind NAT gateways, making static > configuration impossible. The Auto Discovery VPN solution will > address these requirements. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From hannes@juniper.net Wed Jun 12 00:14: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 1652521F9BCF for ; Wed, 12 Jun 2013 00:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_2=2.5, 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 9ShUCQ-NmIc3 for ; Wed, 12 Jun 2013 00:14:39 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id C02E821F992A for ; Wed, 12 Jun 2013 00:14:29 -0700 (PDT) Received: from mail166-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Jun 2013 07:14:28 +0000 Received: from mail166-va3 (localhost [127.0.0.1]) by mail166-va3-R.bigfish.com (Postfix) with ESMTP id ADFEE26011B for ; Wed, 12 Jun 2013 07:14:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zzzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah8275dhz2fh2a8h683h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1e23h1155h) Received-SPF: pass (mail166-va3: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=hannes@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail166-va3 (localhost.localdomain [127.0.0.1]) by mail166-va3 (MessageSwitch) id 1371021267190398_31608; Wed, 12 Jun 2013 07:14:27 +0000 (UTC) Received: from VA3EHSMHS043.bigfish.com (unknown [10.7.14.236]) by mail166-va3.bigfish.com (Postfix) with ESMTP id 2113136004B for ; Wed, 12 Jun 2013 07:14:27 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.50) by VA3EHSMHS043.bigfish.com (10.7.99.53) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Jun 2013 07:14:26 +0000 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, 12 Jun 2013 00:14:25 -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, 12 Jun 2013 00:14:24 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.16) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Jun 2013 00:18:12 -0700 Received: from mail220-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Jun 2013 07:14:23 +0000 Received: from mail220-va3 (localhost [127.0.0.1]) by mail220-va3-R.bigfish.com (Postfix) with ESMTP id B83E96401EF for ; Wed, 12 Jun 2013 07:14:23 +0000 (UTC) Received: from mail220-va3 (localhost.localdomain [127.0.0.1]) by mail220-va3 (MessageSwitch) id 1371021261924046_23346; Wed, 12 Jun 2013 07:14:21 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.244]) by mail220-va3.bigfish.com (Postfix) with ESMTP id D94D5300062; Wed, 12 Jun 2013 07:14:21 +0000 (UTC) Received: from BLUPRD0512HT003.namprd05.prod.outlook.com (132.245.1.149) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Jun 2013 07:14:21 +0000 Received: from flinder-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.215.164) with Microsoft SMTP Server (TLS) id 14.16.324.0; Wed, 12 Jun 2013 07:14:20 +0000 From: Hannes Gredler Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jun 2013 09:14:15 +0200 Message-ID: <9E00A69C-6873-4D33-8269-126E9BE3FEA8@juniper.net> To: John Scudder , Susan Hares MIME-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.54.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NDZH.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Cc: "idr@ietf. org" Subject: [Idr] BGP PA codepoint for draft-ietf-idr-ls-distribution 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, 12 Jun 2013 07:14:47 -0000 hi john and sue, on behalf of the authors of draft-ietf-idr-ls-distribution i am requesting a code point for the LSDIST PA from the BGP Path Attributes registry as per early allocation procedures RFC 4020. = http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xml#bgp-para= meters-2 the spec has now stabilized and we do not expect much change in the = protocol format. thanks, /hannes= From yakov@juniper.net Wed Jun 12 07:33:54 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EBA21F9BEE for ; Wed, 12 Jun 2013 07:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, 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 MYVv2o7hqUCp for ; Wed, 12 Jun 2013 07:33:39 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8F58921F9BD5 for ; Wed, 12 Jun 2013 07:33:39 -0700 (PDT) Received: from mail29-co1-R.bigfish.com (10.243.78.235) by CO1EHSOBE032.bigfish.com (10.243.66.97) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Jun 2013 14:33:37 +0000 Received: from mail29-co1 (localhost [127.0.0.1]) by mail29-co1-R.bigfish.com (Postfix) with ESMTP id 95F6F720202; Wed, 12 Jun 2013 14:33:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz936eIc85fhdb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1155h) Received-SPF: pass (mail29-co1: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=yakov@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; Received: from mail29-co1 (localhost.localdomain [127.0.0.1]) by mail29-co1 (MessageSwitch) id 1371047615947404_20289; Wed, 12 Jun 2013 14:33:35 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.245]) by mail29-co1.bigfish.com (Postfix) with ESMTP id E466EDC005C; Wed, 12 Jun 2013 14:33:35 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.51) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Jun 2013 14:33:34 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Jun 2013 07:33:32 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r5CEXWL75028; Wed, 12 Jun 2013 07:33:32 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201306121433.r5CEXWL75028@magenta.juniper.net> To: , Susan Hares MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62120.1371047611.1@juniper.net> Date: Wed, 12 Jun 2013 07:33:32 -0700 From: Yakov Rekhter X-OriginatorOrg: juniper.net Cc: idr@ietf.org, erosen@cisco.com 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: Wed, 12 Jun 2013 14:33:55 -0000 Sue and John, The authors of draft-rosen-idr-extcomm-iana-00.txt would like the IDR WG to accept this draft as an IDR WG document. Yakov & Eric. ------- Forwarded Message Date: Fri, 31 May 2013 11:47:38 -0400 From: Eric Rosen To: IDR WG Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt - --=-=-= 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: AiwBAMCQp1EMFjoenGdsb2JhbABZgmhRjG22JxYOAQEBAQEGDQ kJFCiCJQEBBAEBNwYBAQQKHgwCAwECBgJACAgDASNJBQSIBQIJqFCEPgEFjkoGjzmDQYkjik2DUAGBK Yp3hEKEDQ 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 (Post fix) 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 Ma y 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 - --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr - --=-=-=-- ------- End of Forwarded Message From randy@psg.com Wed Jun 12 08:08:03 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE0011E80BA for ; Wed, 12 Jun 2013 08:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 c55H0wS4D2fQ for ; Wed, 12 Jun 2013 08:07:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 22E7021F99DD for ; Wed, 12 Jun 2013 08:07:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UmmeI-000LrF-TD; Wed, 12 Jun 2013 15:07:47 +0000 Date: Wed, 12 Jun 2013 17:07:43 +0200 Message-ID: From: Randy Bush To: Yakov Rekhter In-Reply-To: <201306121433.r5CEXWL75028@magenta.juniper.net> References: <201306121433.r5CEXWL75028@magenta.juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: erosen@cisco.com, Susan Hares , idr@ietf.org Subject: Re: [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: Wed, 12 Jun 2013 15:08:03 -0000 > The authors of draft-rosen-idr-extcomm-iana-00.txt would like > the IDR WG to accept this draft as an IDR WG document. i have read and support adoption as to content, i find the process for adding, especially a new type, a little loosey goosey. perhaps an expert or a wg consultation would reduce regrets randy From jrmitche@puck.nether.net Thu Jun 13 21:34:54 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6E621F991F for ; Thu, 13 Jun 2013 21:34:54 -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 Gbcocu-pO+xG for ; Thu, 13 Jun 2013 21:34:54 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9A21F98AD for ; Thu, 13 Jun 2013 21:34:54 -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 r5E4Yoit000672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Jun 2013 00:34:50 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r5E4YoNn000671; Fri, 14 Jun 2013 00:34:50 -0400 Date: Fri, 14 Jun 2013 00:34:49 -0400 From: Jon Mitchell To: Yakov Rekhter Message-ID: <20130614043449.GA21715@puck.nether.net> References: <201306121433.r5CEXWL75028@magenta.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201306121433.r5CEXWL75028@magenta.juniper.net> 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]); Fri, 14 Jun 2013 00:34:50 -0400 (EDT) Cc: idr@ietf.org, erosen@cisco.com Subject: Re: [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, 14 Jun 2013 04:34:55 -0000 On 12/06/13 07:33 -0700, Yakov Rekhter wrote: > Sue and John, > > The authors of draft-rosen-idr-extcomm-iana-00.txt would like > the IDR WG to accept this draft as an IDR WG document. > Support adoption, comments below can be sorted out after acceptance... A few comments or questions - not an implementor so possibly off base on a few of these: Section 3 - nit - it's not totally clear that RFC5701 defines the two high order octets as "Type Field". It certainly implies it, but calls it by various other names throughout. Section 4 - Can I suggest "Standards Action" for new Types, or at least something more specific than request to IANA. Section 5.1.1 - first thought it was mistake that simpson draft had full type considering all other flowspec actions are sub-type of experimental, but guess this is a point to take up with those authors (although draft expired). Might be easier if you specify in paranthesis no sub-types for 0x04, 0x05, 0x08. 0x06 could use standard wording of "Sub-types are defined in..." Section 5.2 - it would be easier to understand I think if you split transitive and non-transitive sub-types into seperate sub-sections. Section 5.2.1 - this doesn't mention if it's transitive / non-transitive, mute if you follow advice above. Also - would it make sense to order these sub-sections by type order? Section 5.2.2 - Section header says Transitive, Registry Name says Non-Transitive? Section 5.2.10 - this section nor anywhere else in document talks about Traffic Actions (for flow spec) which is currently referenced in BGP Extended Communities registry - will it be removed from the registry or should 0x07 just have a comment/reference to it's seperate registry? Section 6 - should you just change title of Section 5 then? Section 10 - Considering this redefines every registry and has content in it, maybe a note to IANA/RFC Editor to hold publication until URL references to the actual re-organized IANA registries, which will be more useful to future readers than stale content in Section 5. Thanks, -Jon From hyojekim@cisco.com Fri Jun 14 16:08:54 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E9021E8083 for ; Fri, 14 Jun 2013 16:08:54 -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=[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 l2hDQELUm9Qm for ; Fri, 14 Jun 2013 16:08:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CBD4021E805D for ; Fri, 14 Jun 2013 16:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1588; q=dns/txt; s=iport; t=1371251328; x=1372460928; h=from:to:subject:date:message-id:mime-version; bh=hnyByAI5Xy14Txj/0zY+dw5dyBMj03zOyaRh8QSXkUI=; b=IZ1Ow5Rh/LzblstdVQqwfyZGiT5/LCyFFfBz43jXvQzdBHMfnYponBF+ NJAIOAVZuBkBp7d1nzepmUKOmowlxFPznk6N/0uo2vrTKAc8kcOXbXNps Px2KH4VRSnkr6gEIcwmLbh+TOOHwkIiYHcibi4jBDQsZ9DObiW9QTOt8I Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8GAH6hu1GtJV2Z/2dsb2JhbABbgkUjIXm+RoEMFm0HghoLAQSBCwELAR5WJwQbDId5AQGZbaAdjxeDN2EDqQODD4Io X-IronPort-AV: E=Sophos;i="4.87,868,1363132800"; d="scan'208,217";a="222861363" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 14 Jun 2013 23:08:48 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5EN8mNx030411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Jun 2013 23:08:48 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 18:08:47 -0500 From: "Hyojeong Kim (hyojekim)" To: "idr@ietf.org" Thread-Topic: RFC 5575 flow-spec traffic-rate non-transitive? Thread-Index: AQHOaVQfQ7Dxq1pvkEWy+Yv65iPEXg== Date: Fri, 14 Jun 2013 23:08:47 +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_BB7BDBA82647F94A81FE5689A3D2A728123980E4xmbalnx13ciscoc_" MIME-Version: 1.0 Subject: [Idr] RFC 5575 flow-spec traffic-rate non-transitive? 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, 14 Jun 2013 23:08:54 -0000 --_000_BB7BDBA82647F94A81FE5689A3D2A728123980E4xmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable According to RFC 5575, the type of traffic-rate is 0x8006 and its transitiv= e bit is 0. However, it is mentioned that "the traffic-rate extended community is a non= -transitive extended community across the autonomous-system boundary". Is this indeed the case where we should not honor the transitive bit? Thanks, Hyojeong --_000_BB7BDBA82647F94A81FE5689A3D2A728123980E4xmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

According to RFC 5575, the type of traffic-rate is 0x8006 and its tran= sitive bit is 0. 
However, it is mentioned that "the traffic-rate extended communit= y is a non-transitive extended community across the autonomous-system bound= ary".  
Is this indeed the case where we should not honor the transitive bit?<= /div>


Thanks,
Hyojeong
 
--_000_BB7BDBA82647F94A81FE5689A3D2A728123980E4xmbalnx13ciscoc_-- From erosen@cisco.com Mon Jun 17 06:11:16 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D688B21F9C09 for ; Mon, 17 Jun 2013 06:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 U30YT0ytydql for ; Mon, 17 Jun 2013 06:11:10 -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 F110921F9B38 for ; Mon, 17 Jun 2013 06:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2937; q=dns/txt; s=iport; t=1371474670; x=1372684270; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=LIw4bQhNsf5x/DwdvP5MHDXA9w8zZhdoiG4RiiB0x2c=; b=nHLFkOfcFsSCvoy86/AOVsYo+G4D/tY7XGYyb+hDTzL32QX95syPhxm+ xUrsGgqkZFyGLZX6gt9A2Fvhl2t3Z+7zm9odgYAxUsc5vzbl2GBQRq63k JhH/jZH8t6EqF0WCT9aOcEEu683+1GnSyYlijvcdQxpsAiuSpY3ptWyji w=; X-IronPort-AV: E=Sophos;i="4.87,881,1363132800"; d="scan'208";a="223697352" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jun 2013 13:11:08 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5HDB70d009102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 13:11:07 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 r5HDB6sW023361; Mon, 17 Jun 2013 09:11:06 -0400 From: Eric Rosen To: Jon Mitchell In-reply-to: Your message of Fri, 14 Jun 2013 00:34:49 -0400. <20130614043449.GA21715@puck.nether.net> Date: Mon, 17 Jun 2013 09:11:06 -0400 Message-ID: <23360.1371474666@erosen-linux> Cc: Yakov Rekhter , erosen@cisco.com, idr@ietf.org Subject: Re: [Idr] draft-rosen-idr-extcomm-iana-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:11:16 -0000 Thanks for taking the time to read through all the tedious details! > Section 6 - should you just change title of Section 5 then? Yes, that seems like a sensible idea. > Considering this redefines every registry and has content > in it, maybe a note to IANA/RFC Editor to hold publication until URL > references to the actual re-organized IANA registries, which will be > more useful to future readers than stale content in Section 5. Generally an RFC is not published until the IANA actions are completed; there's a "waiting for IANA" state as part of the RFC Editor's workflow, and IANA always (at least in my experience) verifies with the authors that the proper IANA actions are being taken. > Section 5.2.2 - Section header says Transitive, Registry Name says > Non-Transitive? Did you mean section 5.2.10? The registry name should say "transitive". > Section 5.2.10 - this section nor anywhere else in document talks about > Traffic Actions (for flow spec) which is currently referenced in BGP > Extended Communities registry - will it be removed from the registry or > should 0x07 just have a comment/reference to it's separate registry? I overlooked this one. I think the proper way to handle it is with the following entry in the "BGP Generic Non-Transitive Experimental Use Extended Community Sub-Types" registry: 0x07 Flow spec traffic-action (Use of the Value field is defined in the "Traffic Actions Field" registry.) > Section 5.1.1 - first thought it was mistake that simpson draft had > full type considering all other flowspec actions are sub-type of > experimental, but guess this is a point to take up with those authors Looking at draft-simpson-idr-flowspec-redirect, I see it defines a transitive type (0x08), but it doesn't seem to define any sub-types, even though it requests an "extended type". Under the proposed reorganization, the authors would have specify whether they want a Sub-Type registry for the second octet, or whether they want to treat the second octet as part of the value field. > 0x06 could use standard wording of "Sub-types are defined in..." Yes, good point. > Section 5.2 - it would be easier to understand I think if you split > transitive and non-transitive sub-types into seperate sub-sections. I don't think that would be right, because the transitive/intransitive distinction is part of the Type field, not part of the Sub-Type field. It should be possible for a Sub-Type registry to be shared between a transitive Type and an intransitive Type (although there are no current examples of that). > Section 4 - Can I suggest "Standards Action" for new Types, or at > least something more specific than request to IANA. Both Type registries (and the Sub-Type registries as well) have defined registration policies for specific value ranges. From hyojekim@cisco.com Mon Jun 17 11:23:03 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765C821F9C62 for ; Mon, 17 Jun 2013 11:23:03 -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=[AWL=0.000, 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 oQCKKC+NM-Bd for ; Mon, 17 Jun 2013 11:22:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CE3FE21F9D73 for ; Mon, 17 Jun 2013 11:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3460; q=dns/txt; s=iport; t=1371493362; x=1372702962; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0EwLoYKlxh+dGCs/q1P73hvkMdH2jSP+jh9X7oPRu6Q=; b=iRkQfrjPBFHYspvXuqoGQofEjx3+qWpT0pA8JJCNvNiyDLy/yv3R/QD9 DGoz3/rEls0hb7mWBby1xpZAIKFQ18RWVjVh9lPcRKzu0c13bfM6uOmMw A/0vLdWj5aG8ujUr2VG47Om8ZuFPw0XTspTuNUnRXsHPI4Rn73ovdM32U Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHlSv1GtJV2d/2dsb2JhbABbgmghMUm+e34WdIIlAQQBAQE3NAsSAQgiFDcLJQIEAQ0FCAyHeQEBC7l4BI8WMQeCf2EDjDKSIYoxgw+CKA X-IronPort-AV: E=Sophos;i="4.87,882,1363132800"; d="scan'208";a="223832076" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jun 2013 18:22:42 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5HIMg3D031532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Jun 2013 18:22:42 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 13:22:41 -0500 From: "Hyojeong Kim (hyojekim)" To: "Eric Rosen (erosen)" , Jon Mitchell Thread-Topic: [Idr] draft-rosen-idr-extcomm-iana-00.txt Thread-Index: AQHOa1wuVL8zU1AOVkS/NHEo+/386pk6FwqA Date: Mon, 17 Jun 2013 18:22:41 +0000 Message-ID: In-Reply-To: <23360.1371474666@erosen-linux> 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: text/plain; charset="us-ascii" Content-ID: <18183224A5020540A2243A0CCD9C53B1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Yakov Rekhter , "idr@ietf.org" Subject: Re: [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: Mon, 17 Jun 2013 18:23:04 -0000 Looking at your comment below, you treat all the flowspec action extcomms as transitive. However, RFC 5575 says that traffic-rate is a non-transitive extended community across the AS boundary. Have you checked about it? Thanks, Hyojeong On 6/17/13 6:11 AM, "Eric Rosen (erosen)" wrote: >Thanks for taking the time to read through all the tedious details! > >> Section 6 - should you just change title of Section 5 then? > >Yes, that seems like a sensible idea. > >> Considering this redefines every registry and has content >> in it, maybe a note to IANA/RFC Editor to hold publication until URL >> references to the actual re-organized IANA registries, which will be >> more useful to future readers than stale content in Section 5. > >Generally an RFC is not published until the IANA actions are completed; >there's a "waiting for IANA" state as part of the RFC Editor's workflow, >and >IANA always (at least in my experience) verifies with the authors that the >proper IANA actions are being taken. > >> Section 5.2.2 - Section header says Transitive, Registry Name says >> Non-Transitive? > >Did you mean section 5.2.10? The registry name should say "transitive". > >> Section 5.2.10 - this section nor anywhere else in document talks about >> Traffic Actions (for flow spec) which is currently referenced in BGP >> Extended Communities registry - will it be removed from the registry or >> should 0x07 just have a comment/reference to it's separate registry? > >I overlooked this one. I think the proper way to handle it is with the >following entry in the "BGP Generic Non-Transitive Experimental Use >Extended Community Sub-Types" registry: > > 0x07 Flow spec traffic-action (Use of the Value field is >defined > in the "Traffic Actions Field" registry.) > >> Section 5.1.1 - first thought it was mistake that simpson draft had >> full type considering all other flowspec actions are sub-type of >> experimental, but guess this is a point to take up with those authors > >Looking at draft-simpson-idr-flowspec-redirect, I see it defines a >transitive type (0x08), but it doesn't seem to define any sub-types, even >though it requests an "extended type". Under the proposed reorganization, >the authors would have specify whether they want a Sub-Type registry for >the >second octet, or whether they want to treat the second octet as part of >the >value field.=20 > >> 0x06 could use standard wording of "Sub-types are defined in..." > >Yes, good point. > >> Section 5.2 - it would be easier to understand I think if you split >> transitive and non-transitive sub-types into seperate sub-sections. > >I don't think that would be right, because the transitive/intransitive >distinction is part of the Type field, not part of the Sub-Type field. It >should be possible for a Sub-Type registry to be shared between a >transitive >Type and an intransitive Type (although there are no current examples of >that). > >> Section 4 - Can I suggest "Standards Action" for new Types, or at >> least something more specific than request to IANA. > >Both Type registries (and the Sub-Type registries as well) have defined >registration policies for specific value ranges. > > > > > =20 >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From jrmitche@puck.nether.net Mon Jun 17 14:33:26 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F5721F9DFB for ; Mon, 17 Jun 2013 14:33:26 -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 l06F5+SCM8JD for ; Mon, 17 Jun 2013 14:33:25 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7C91F21F9DF2 for ; Mon, 17 Jun 2013 14:33:25 -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 r5HLXL8P010344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Jun 2013 17:33:21 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r5HLXLgd010343; Mon, 17 Jun 2013 17:33:21 -0400 Date: Mon, 17 Jun 2013 17:33:21 -0400 From: Jon Mitchell To: Eric Rosen Message-ID: <20130617213321.GA7831@puck.nether.net> References: <20130614043449.GA21715@puck.nether.net> <23360.1371474666@erosen-linux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23360.1371474666@erosen-linux> 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, 17 Jun 2013 17:33:21 -0400 (EDT) Cc: Yakov Rekhter , idr@ietf.org Subject: Re: [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: Mon, 17 Jun 2013 21:33:26 -0000 On 17/06/13 09:11 -0400, Eric Rosen wrote: > > Considering this redefines every registry and has content > > in it, maybe a note to IANA/RFC Editor to hold publication until URL > > references to the actual re-organized IANA registries, which will be > > more useful to future readers than stale content in Section 5. > > Generally an RFC is not published until the IANA actions are completed; > there's a "waiting for IANA" state as part of the RFC Editor's workflow, and > IANA always (at least in my experience) verifies with the authors that the > proper IANA actions are being taken. > Eric - this is understood - what I meant to ask is explicitly put a normative reference to the existing URL (assuming it will be rebuilt in same place), and reference that in section 5. Also, putting a note in the draft with instructions to RFC Editor (for removal upon publication), to ensure that the proper final URL reference is included in the RFC. By the current reading of the draft, this could be published as an RFC and all the IANA actions to re-organize the registries coudld be done and this RFC would not have a URL reference to the registry. > > Section 5.2.2 - Section header says Transitive, Registry Name says > > Non-Transitive? > > Did you mean section 5.2.10? The registry name should say "transitive". > Yes, sorry. > > Section 5.2.10 - this section nor anywhere else in document talks about > > Traffic Actions (for flow spec) which is currently referenced in BGP > > Extended Communities registry - will it be removed from the registry or > > should 0x07 just have a comment/reference to it's separate registry? > > I overlooked this one. I think the proper way to handle it is with the > following entry in the "BGP Generic Non-Transitive Experimental Use > Extended Community Sub-Types" registry: > > 0x07 Flow spec traffic-action (Use of the Value field is defined > in the "Traffic Actions Field" registry.) > Sounds good. > > > Section 5.2 - it would be easier to understand I think if you split > > transitive and non-transitive sub-types into seperate sub-sections. > > I don't think that would be right, because the transitive/intransitive > distinction is part of the Type field, not part of the Sub-Type field. It > should be possible for a Sub-Type registry to be shared between a transitive > Type and an intransitive Type (although there are no current examples of > that). OK - I thought a sub-type registry would be required to be defined for each seperately (even if the values matched). Thanks for clarifying. > > > Section 4 - Can I suggest "Standards Action" for new Types, or at > > least something more specific than request to IANA. > > Both Type registries (and the Sub-Type registries as well) have defined > registration policies for specific value ranges. Yes, I see it more clearly on second pass it's mentioned in Section 5 and Section 2. From jhaas@slice.pfrc.org Tue Jun 18 11:52:09 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C09311E80EE for ; Tue, 18 Jun 2013 11:52:09 -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 t7GU4ECsqXd5 for ; Tue, 18 Jun 2013 11:52:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E09EE21F9A69 for ; Tue, 18 Jun 2013 11:52:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A98F9C2A5; Tue, 18 Jun 2013 14:52:02 -0400 (EDT) Date: Tue, 18 Jun 2013 14:52:02 -0400 From: Jeffrey Haas To: Yakov Rekhter Message-ID: <20130618185202.GC3241@pfrc> References: <201306121433.r5CEXWL75028@magenta.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201306121433.r5CEXWL75028@magenta.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: erosen@cisco.com, Susan Hares , idr@ietf.org Subject: Re: [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: Tue, 18 Jun 2013 18:52:09 -0000 On Wed, Jun 12, 2013 at 07:33:32AM -0700, Yakov Rekhter wrote: > The authors of draft-rosen-idr-extcomm-iana-00.txt would like > the IDR WG to accept this draft as an IDR WG document. I support adopting this draft. I was always mildly cheesed about the fact that the transitive bit really meant that you could have a code point such that masking the transitive bit doesn't guarantee a distinct set of encodings. At the moment, the registry continues to contain values that could let this be the case, but I think that particular ship has sailed. (E.g. 0x5 is Cos, but there's no non-transitive form of it. If someone asks for a new non-transitive value, 0x5 may be assigned and mean something completely different.) Since the draft cites a number of code points for specifications in-flight, getting this draft all the way through RFC status will be fun. Please make sure to update the normative references to cover all of those code points. -- Jeff From jhaas@slice.pfrc.org Tue Jun 18 12:51: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 5CEA621F9926 for ; Tue, 18 Jun 2013 12:51:20 -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 SJQdgK2v0Du7 for ; Tue, 18 Jun 2013 12:51:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5383321F9695 for ; Tue, 18 Jun 2013 12:51:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D4E42C5E1; Tue, 18 Jun 2013 15:51:14 -0400 (EDT) Date: Tue, 18 Jun 2013 15:51:14 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20130618195114.GE3241@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] Question on forwarding behavior in draft-ietf-idr-flowspec-redirect 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, 18 Jun 2013 19:51:20 -0000 Authors, : When a BGP speaker receives an UPDATE message with the redirect-to- : IP extended community it is expected to create a traffic filtering : rule for every flow-spec NLRI in the message that has this path as : its best path. 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. More specifically: if an : IPv4 [or IPv6] packet with destination address D that is normally : forwarded to a next-hop A matches a filter entry of the type : described above it MUST instead be redirected (C=0) or mirrored : (C=1) to next-hop B, where B is found by FIB lookup of the IPv4 [or : IPv6] address contained in the MP_REACH_NLRI next-hop field (i.e. a : longest-prefix-match lookup). Signaling and applying constraints : beyond longest-prefix-match on the types of interfaces or tunnels : that can be used as the redirection next-hop B are not precluded by : this specification but are nevertheless outside its scope. The text above raises some question with regard to mixed-address family behavior. To illustrate, we have four examples of IP-based forwarding: *IPv4 traffic over IPv4 forwarding IPv6 traffic over IPv4 forwarding IPv4 traffic over IPv6 forwarding *IPv6 traffic over IPv6 forwarding The cases noted with an asterisk aren't exciting - you'd expect them to just work regardless of whether the nexthop sent in the flowspec route is either an adjacent IP system or a tunnel covering the same address family. The other two cases are the interesting ones. One normally wouldn't expect IPv6 traffic to be IP forwarded to an IPv4 nexthop, or vice-versa. When the nexthop actually maps to a tunnel (e.g. MPLS), the case is perhaps a bit more ambiguous: Does the egress of the tunnel inspect the traffic to determine the proper ethertype for the traffic? This is admittedly not an immediate problem today. 5575 and the matching extension to do IPv6 currently expect the address family of the flowspec route to have an appropriate same-family MP-NEXTHOP. Put a somewhat different way, if the expected behavior is that you'll always have a nexthop for redirect that is of the same address family as the flowspec route, we're perhaps done. Until we decide we want to do flowspec for something besides plain IP. But that is perhaps a different problem to worry about later. -- Jeff From shares@ndzh.com Mon Jun 24 11:24:46 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89F421E8127 for ; Mon, 24 Jun 2013 11:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[AWL=1.002, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, J_CHICKENPOX_26=0.6, J_CHICKENPOX_44=0.6] 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 kL4f5ZLQldKU for ; Mon, 24 Jun 2013 11:24:40 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A12B521E811A for ; Mon, 24 Jun 2013 11:24:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Yakov Rekhter'" , References: <201306121433.r5CEXWL75028@magenta.juniper.net> In-Reply-To: <201306121433.r5CEXWL75028@magenta.juniper.net> Date: Mon, 24 Jun 2013 14:24:28 -0400 Message-ID: <014501ce7108$117e73e0$347b5ba0$@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: AQIDR85aGaIx8/WUX2vTxdLZAOFmsJjbgBEg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: idr@ietf.org, erosen@cisco.com Subject: Re: [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: Mon, 24 Jun 2013 18:24:47 -0000 Yakov and John: I've not seen John's official call for the acceptance of this draft as WG-Draft. We will extend this call until 7/5/13. Sue Hares -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Wednesday, June 12, 2013 10:34 AM To: jgs@juniper.net; Susan Hares Cc: idr@ietf.org; erosen@cisco.com Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt Sue and John, The authors of draft-rosen-idr-extcomm-iana-00.txt would like the IDR WG to accept this draft as an IDR WG document. Yakov & Eric. ------- Forwarded Message Date: Fri, 31 May 2013 11:47:38 -0400 From: Eric Rosen To: IDR WG Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt - --=-=-= 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: AiwBAMCQp1EMFjoenGdsb2JhbABZgmhRjG22JxYOAQEBAQEGDQ kJFCiCJQEBBAEBNwYBAQQKHgwCAwECBgJACAgDASNJBQSIBQIJqFCEPgEFjkoGjzmDQYkjik2DUA GBK Yp3hEKEDQ 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 (Post fix) 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 Ma y 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 - --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr - --=-=-=-- ------- End of Forwarded Message From internet-drafts@ietf.org Mon Jun 24 14:21:01 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828BA21E812C; Mon, 24 Jun 2013 14:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.095, 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 YVDTVY-xQvR6; Mon, 24 Jun 2013 14:21:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5B511E8143; Mon, 24 Jun 2013 14:21:00 -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.51.p2 Message-ID: <20130624212100.9086.5103.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2013 14:21:00 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-enhanced-route-refresh-04.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, 24 Jun 2013 21:21:01 -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 : Enhanced Route Refresh Capability for BGP-4 Author(s) : Keyur Patel Enke Chen Balaji Venkatachalapathy Filename : draft-ietf-idr-bgp-enhanced-route-refresh-04.txt Pages : 6 Date : 2013-06-24 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 on-line, non-disruptive consistency validations of BGP routing updates. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-enhanced-route-refres= h-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jun 24 14:29:09 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611DB11E8194; Mon, 24 Jun 2013 14:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, 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 Fw-emNi1DlX9; Mon, 24 Jun 2013 14:29:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0656B11E8143; Mon, 24 Jun 2013 14:29:09 -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.51.p2 Message-ID: <20130624212908.23226.49791.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2013 14:29:08 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-enhanced-gr-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, 24 Jun 2013 21:29:09 -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 : Accelerated Routing Convergence for BGP Graceful Restart Author(s) : Keyur Patel Enke Chen Rex Fernando John Scudder Filename : draft-ietf-idr-enhanced-gr-03.txt Pages : 9 Date : 2013-06-24 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-enhanced-gr-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jun 24 14:40:54 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A980E21F9452; Mon, 24 Jun 2013 14:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, 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 GYYiq30ZZ2BM; Mon, 24 Jun 2013 14:40:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 006BF21E814A; Mon, 24 Jun 2013 14:40:54 -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.51.p2 Message-ID: <20130624214053.5027.73193.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2013 14:40:53 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-04.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, 24 Jun 2013 21:40:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Revised Error Handling for BGP UPDATE Messages Author(s) : John G. Scudder Enke Chen Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-04.txt Pages : 12 Date : 2013-06-24 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-error-handling-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jun 24 19:01:01 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6972421F9D65; Mon, 24 Jun 2013 19:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.082, 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 odGkNikzl4m6; Mon, 24 Jun 2013 19:01:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DF321F9007; Mon, 24 Jun 2013 19:01:00 -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.51.p2 Message-ID: <20130625020100.8259.37613.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2013 19:01:00 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-add-paths-guidelines-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, 25 Jun 2013 02:01:01 -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 : Best Practices for Advertisement of Multiple Paths in IB= GP Author(s) : Jim Uttaro Pierre Francois Roberto Fragassi Adam Simpson Keyur Patel Filename : draft-ietf-idr-add-paths-guidelines-05.txt Pages : 24 Date : 2013-06-24 Abstract: Add-Paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. This provides a number of potential benefits, including reduced routing churn, faster convergence and better loadsharing. This document provides recommendations to implementers of Add-Paths so that network operators have the tools needed to address their specific applications and to manage the scalability impact of Add- Paths. A router implementing Add-Paths may learn many paths for a prefix and must decide which of these to advertise to peers. This document analyses different algorithms for making this selection and provides recommendations based on the target application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-guidelines There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-add-paths-guidelines-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-add-paths-guidelines-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bruno.decraene@orange.com Tue Jun 25 01:22: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 9FF6621F9AFA for ; Tue, 25 Jun 2013 01:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.594 X-Spam-Level: X-Spam-Status: No, score=-0.594 tagged_above=-999 required=5 tests=[AWL=1.404, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, UNPARSEABLE_RELAY=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 oSu6jDkN4sM9 for ; Tue, 25 Jun 2013 01:22:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB3821F99BA for ; Tue, 25 Jun 2013 01:22:11 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 4B664325819; Tue, 25 Jun 2013 10:22:01 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1C9E3238056; Tue, 25 Jun 2013 10:22:01 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 10:22:00 +0200 From: To: Susan Hares , "jgs@juniper.net" Thread-Topic: [Idr] draft-rosen-idr-extcomm-iana-00.txt Thread-Index: AQIDR85aGaIx8/WUX2vTxdLZAOFmsJjbgBEggADS7/A= Date: Tue, 25 Jun 2013 08:21:59 +0000 Message-ID: <13021_1372148521_51C95329_13021_138_1_53C29892C857584299CBF5D05346208A0703526D@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <201306121433.r5CEXWL75028@magenta.juniper.net> <014501ce7108$117e73e0$347b5ba0$@ndzh.com> In-Reply-To: <014501ce7108$117e73e0$347b5ba0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "idr@ietf.org" , "erosen@cisco.com" , 'Yakov Rekhter' Subject: Re: [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: Tue, 25 Jun 2013 08:22:21 -0000 Hi Sue, John, all, I've read and support WG adoption. Bruno >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan >Hares >Sent: Monday, June 24, 2013 8:24 PM >To: 'Yakov Rekhter'; jgs@juniper.net >Cc: idr@ietf.org; erosen@cisco.com >Subject: Re: [Idr] draft-rosen-idr-extcomm-iana-00.txt > >Yakov and John: > >I've not seen John's official call for the acceptance of this draft as >WG-Draft. We will extend this call until 7/5/13. > >Sue Hares > >-----Original Message----- >From: Yakov Rekhter [mailto:yakov@juniper.net] >Sent: Wednesday, June 12, 2013 10:34 AM >To: jgs@juniper.net; Susan Hares >Cc: idr@ietf.org; erosen@cisco.com >Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt > >Sue and John, > >The authors of draft-rosen-idr-extcomm-iana-00.txt would like the IDR WG to >accept this draft as an IDR WG document. > >Yakov & Eric. >------- Forwarded Message > >Date: Fri, 31 May 2013 11:47:38 -0400 >From: Eric Rosen >To: IDR WG >Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt > >- --=3D-=3D-=3D >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. > > > >- --=3D-=3D-=3D >Content-Type: message/rfc822 >Content-Disposition: inline; filename=3D3423 >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=3Dpass (signature >verified > [TEST]) header.i=3D@ietf.org >X-from-outside-Cisco: 12.22.58.30 >X-IronPort-Anti-Spam-Filtered: true >X-IronPort-Anti-Spam-Result: >AiwBAMCQp1EMFjoenGdsb2JhbABZgmhRjG22JxYOAQEBAQEGDQ >kJFCiCJQEBBAEBNwYBAQQKHgwCAwECBgJACAgDASNJBQSIBQIJqFCEPgEFjkoGjzmDQYkjik2D= UA >GBK >Yp3hEKEDQ >X-IronPort-AV: E=3DSophos;i=3D"4.87,772,1363132800"; > d=3D"scan'208";a=3D"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=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org; s= =3Dietf1; > t=3D1369936254; bh=3Df9K8hgMBlrC6IvJlZGQ7gsMdJ1y8H9QLf1OKoW85G7s=3D; > h=3DMIME-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=3DOVexJgUO33kxYqNt/rg6+OrLmO1a2+GxCT13wCvsmy3Pm41a2DfP7BKhFbwdocfzE > PGEjASzZW82rK5JwD/dI59+Byy9b13OLAN/U6q48AApj52j4T0/LrM22gJw89RXKcc > llbJsjQFt0J6nZEn99e+BEszFZa7emUMWv8s2npY=3D >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 >(Post >fix) > 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=3D-102.521 tagged_above=3D-999 required=3D5 > tests=3D[AWL=3D0.079, BAYES_00=3D-2.599, NO_RELAYS=3D-0.001, > USER_IN_WHITELIST=3D-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 >Ma >y > 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=3D"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 > > >- --=3D-=3D-=3D >Content-Type: text/plain; charset=3D"us-ascii" >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr > >- --=3D-=3D-=3D-- > >------- End of Forwarded Message > > > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From bdickson@verisign.com Tue Jun 25 08:11: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 0C2EE21F9E0E for ; Tue, 25 Jun 2013 08:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 SSbw9VXDpsKl for ; Tue, 25 Jun 2013 08:11:29 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id EDCFA21F9DBB for ; Tue, 25 Jun 2013 08:11:27 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUcmzHCT73p5zE96CcTb2owNHhCMnpOC3@postini.com; Tue, 25 Jun 2013 08:11:29 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r5PFBLRC004129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Jun 2013 11:11:21 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 11:11:20 -0400 From: "Dickson, Brian" To: Susan Hares , "jgs@juniper.net" Thread-Topic: [Idr] draft-rosen-idr-extcomm-iana-00.txt Thread-Index: AQHOcQgjNM8EqFL+n0OxDutohfLds5lGWx2AgAAvTgA= Date: Tue, 25 Jun 2013 15:11:20 +0000 Message-ID: In-Reply-To: <13021_1372148521_51C95329_13021_138_1_53C29892C857584299CBF5D05346208A0703526D@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "erosen@cisco.com" , 'Yakov Rekhter' Subject: Re: [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: Tue, 25 Jun 2013 15:11:34 -0000 I too have read this, and support WG adoption. Brian On 6/25/13 4:21 AM, "bruno.decraene@orange.com" wrote: >Hi Sue, John, all, > >I've read and support WG adoption. > >Bruno > >>-----Original Message----- >>From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of >>Susan >>Hares >>Sent: Monday, June 24, 2013 8:24 PM >>To: 'Yakov Rekhter'; jgs@juniper.net >>Cc: idr@ietf.org; erosen@cisco.com >>Subject: Re: [Idr] draft-rosen-idr-extcomm-iana-00.txt >> >>Yakov and John: >> >>I've not seen John's official call for the acceptance of this draft as >>WG-Draft. We will extend this call until 7/5/13. >> >>Sue Hares >> >>-----Original Message----- >>From: Yakov Rekhter [mailto:yakov@juniper.net] >>Sent: Wednesday, June 12, 2013 10:34 AM >>To: jgs@juniper.net; Susan Hares >>Cc: idr@ietf.org; erosen@cisco.com >>Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt >> >>Sue and John, >> >>The authors of draft-rosen-idr-extcomm-iana-00.txt would like the IDR WG >>to >>accept this draft as an IDR WG document. >> >>Yakov & Eric. >>------- Forwarded Message >> >>Date: Fri, 31 May 2013 11:47:38 -0400 >>From: Eric Rosen >>To: IDR WG >>Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt >> >>- --=3D-=3D-=3D >>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. >> >> >> >>- --=3D-=3D-=3D >>Content-Type: message/rfc822 >>Content-Disposition: inline; filename=3D3423 >>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=3Dpass (signature >>verified >> [TEST]) header.i=3D@ietf.org >>X-from-outside-Cisco: 12.22.58.30 >>X-IronPort-Anti-Spam-Filtered: true >>X-IronPort-Anti-Spam-Result: >>AiwBAMCQp1EMFjoenGdsb2JhbABZgmhRjG22JxYOAQEBAQEGDQ >>kJFCiCJQEBBAEBNwYBAQQKHgwCAwECBgJACAgDASNJBQSIBQIJqFCEPgEFjkoGjzmDQYkjik2 >>DUA >>GBK >>Yp3hEKEDQ >>X-IronPort-AV: E=3DSophos;i=3D"4.87,772,1363132800"; >> d=3D"scan'208";a=3D"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=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org; = s=3Dietf1; >> t=3D1369936254; bh=3Df9K8hgMBlrC6IvJlZGQ7gsMdJ1y8H9QLf1OKoW85G7s=3D; >> h=3DMIME-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=3DOVexJgUO33kxYqNt/rg6+OrLmO1a2+GxCT13wCvsmy3Pm41a2DfP7BKhFbwdocfzE >> PGEjASzZW82rK5JwD/dI59+Byy9b13OLAN/U6q48AApj52j4T0/LrM22gJw89RXKcc >> llbJsjQFt0J6nZEn99e+BEszFZa7emUMWv8s2npY=3D >>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 >>(Post >>fix) >> 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=3D-102.521 tagged_above=3D-999 required=3D5 >> tests=3D[AWL=3D0.079, BAYES_00=3D-2.599, NO_RELAYS=3D-0.001, >> USER_IN_WHITELIST=3D-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 >>Ma >>y >> 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=3D"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 >> >> >>- --=3D-=3D-=3D >>Content-Type: text/plain; charset=3D"us-ascii" >>MIME-Version: 1.0 >>Content-Transfer-Encoding: 7bit >>Content-Disposition: inline >> >>_______________________________________________ >>Idr mailing list >>Idr@ietf.org >>https://www.ietf.org/mailman/listinfo/idr >> >>- --=3D-=3D-=3D-- >> >>------- End of Forwarded Message >> >> >> >>_______________________________________________ >>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 messages >electroniques etant susceptibles d'alteration, >France Telecom - Orange decline toute responsabilite si ce message a ete >altere, deforme ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, France Telecom - Orange is not liable for >messages that have been modified, changed or falsified. >Thank you. > >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From internet-drafts@ietf.org Thu Jun 27 07:28: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 73B0021F9DAE; Thu, 27 Jun 2013 07:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, 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 w6wIVD2xqoUx; Thu, 27 Jun 2013 07:28:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE4F21F9D92; Thu, 27 Jun 2013 07:28:33 -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.51.p2 Message-ID: <20130627142833.21297.87327.idtracker@ietfa.amsl.com> Date: Thu, 27 Jun 2013 07:28:33 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:28:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Inter-domain SLA Exchange Author(s) : Shitanshu Shah Keyur Patel Sandeep Bajaj Luis Tomotaki Mohamed Boucadair Filename : draft-ietf-idr-sla-exchange-01.txt Pages : 24 Date : 2013-06-27 Abstract: Network administrators typically provision QoS (Quality of Service) policies for their application traffic (such as voice, video) based on SLAs (Service Level Agreements) negotiated with their providers, and translate those SLAs to vendor specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, many times manual, process and prone to errors. This document proposes an in-band method of SLA signaling which can help to simplify some of the complexities. This document defines an operational transitive attribute to signal SLA details in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplify and speed-up some of the complex provisioning tasks. Though the use case with the proposed attribute is explicitly defined in this document, purpose of this attribute is not limited to this use case only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sla-exchange-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From svshah@cisco.com Thu Jun 27 07:37: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 7439121F9DC9; Thu, 27 Jun 2013 07:37:11 -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 2vbcwQcYqH+D; Thu, 27 Jun 2013 07:37:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C04DE21F9D7F; Thu, 27 Jun 2013 07:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2789; q=dns/txt; s=iport; t=1372343823; x=1373553423; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=PwtCkAbTcvQtBdJpevg5SI0NRM6VOz/io8FQnr0c1Io=; b=a+09tbJRkCzmhvHixbQQBtJGB8wZLx6/hVkKpKKcZcYE+xTtLEfxfxJQ 7jpOFqYSbC9YiLw8v9ECvxqDSv7TBEkX60Vt610/t9SGWDNRoMQvfb6f2 CByM6tlL/GjZ6lIrNVWCMcyVJzY/IDfAM5QN6SB778z0tWAKy672Twcj2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAK9MzFGtJV2Z/2dsb2JhbABbgwkxQwa/CX8WdIIjAQEBAQMBAQE3MwEdAQgiFDcLGwEGAwIEARIIAYgFBwW6cI4dgQczBYMCYwOYbop6hSKDEYFoQA X-IronPort-AV: E=Sophos;i="4.87,952,1363132800"; d="scan'208";a="228166289" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 27 Jun 2013 14:37:02 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5REb28L030496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 14:37:02 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 09:37:01 -0500 From: "Shitanshu Shah (svshah)" To: "idr@ietf.org" , "tsvwg@ietf.org" Thread-Topic: I-D Action: draft-ietf-idr-sla-exchange-01.txt Thread-Index: AQHOc0Ki0np6g8+K9U6RkYxz8y4hCplJf5+A Date: Thu, 27 Jun 2013 14:37:00 +0000 Message-ID: In-Reply-To: <20130627142833.21297.87327.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.82.96] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] FW: I-D Action: draft-ietf-idr-sla-exchange-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:37:11 -0000 Dear WG, Following is a revised draft incorporating feed-back/comments from the last IETF. Notable changes from the last revision, - use of IPFIX IANA registry for Classifier Elements - use of Tspec for SLA rates - L2_OVERHEAD attribute to allow SLA advertise L3, L2 or customized L2 rates Please provide comments, Regards, Shitanshu On 6/27/13 7:28 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Inter-Domain Routing Working Group of >the IETF. > > Title : Inter-domain SLA Exchange > Author(s) : Shitanshu Shah > Keyur Patel > Sandeep Bajaj > Luis Tomotaki > Mohamed Boucadair > Filename : draft-ietf-idr-sla-exchange-01.txt > Pages : 24 > Date : 2013-06-27 > >Abstract: > Network administrators typically provision QoS (Quality of Service) > policies for their application traffic (such as voice, video) based > on SLAs (Service Level Agreements) negotiated with their providers, > and translate those SLAs to vendor specific configuration language. > Both learning of SLA, either thru SLA documents or via some other > out-of-band method, and translating them to vendor specific > configuration language is a complex, many times manual, process and > prone to errors. This document proposes an in-band method of SLA > signaling which can help to simplify some of the complexities. > > This document defines an operational transitive attribute to signal > SLA details in-band, across administrative boundaries (considered as > Autonomous Systems (AS)), thus simplify and speed-up some of the > complex provisioning tasks. > > Though the use case with the proposed attribute is explicitly defined > in this document, purpose of this attribute is not limited to this > use case only. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sla-exchange-01 > > >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