From internet-drafts@ietf.org Sun Oct 2 23:50:05 2011 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 651DB21F8AA9; Sun, 2 Oct 2011 23:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, 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 VvOpKxNStAOb; Sun, 2 Oct 2011 23:50:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0640521F851F; Sun, 2 Oct 2011 23:50:05 -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: 3.60 Message-ID: <20111003065005.16731.95041.idtracker@ietfa.amsl.com> Date: Sun, 02 Oct 2011 23:50:05 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-link-bandwidth-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, 03 Oct 2011 06:50:05 -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 Link Bandwidth Extended Community Author(s) : Pradosh Mohapatra Rex Fernando Filename : draft-ietf-idr-link-bandwidth-03.txt Pages : 5 Date : 2011-10-02 This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-link-bandwidth-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-link-bandwidth-03.txt From internet-drafts@ietf.org Fri Oct 7 06:30:02 2011 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 D33E421F8B34; Fri, 7 Oct 2011 06:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 R-3-WL81gR4a; Fri, 7 Oct 2011 06:29:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6446D21F8B23; Fri, 7 Oct 2011 06:29:57 -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: 3.60 Message-ID: <20111007132957.17302.73174.idtracker@ietfa.amsl.com> Date: Fri, 07 Oct 2011 06:29:57 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-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: Fri, 07 Oct 2011 13:30:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of= the IETF. Title : Dissemination of Flow Specification Rules for IPv6 Author(s) : Robert Raszuk Burjiz Pithawala Danny McPherson Filename : draft-ietf-idr-flow-spec-v6-01.txt Pages : 8 Date : 2011-10-07 Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-v6-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-v6-01.txt From brian.e.carpenter@gmail.com Fri Oct 7 12:06:13 2011 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 B255821F8C2F for ; Fri, 7 Oct 2011 12:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, 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 onBBv-timFtr for ; Fri, 7 Oct 2011 12:06:13 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1557121F8C1E for ; Fri, 7 Oct 2011 12:06:13 -0700 (PDT) Received: by gyd12 with SMTP id 12so4736372gyd.31 for ; Fri, 07 Oct 2011 12:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uxAOXl90DfDG7a+JiN/tiAsTE3YarlzZ6gPbQq/Ggv4=; b=j//Io9wKleU/gT4YUonWJ7JAlc13nSwUGpEn8MUHBaeOXACrGVK3cawA6Ii8Q8wErU u4fQf5mgwmTKaoi0uuHzRdCPglh2AJ4vGxGWuD+oXfwIshg6dpqJGF6vh+LNRM/VKQMk Ec6IttpMlpXoeJBIxn2XkkV1zFyOqji3Ez7ko= Received: by 10.223.63.75 with SMTP id a11mr12609886fai.9.1318014566901; Fri, 07 Oct 2011 12:09:26 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id a7sm14101547fam.22.2011.10.07.12.09.23 (version=SSLv3 cipher=OTHER); Fri, 07 Oct 2011 12:09:25 -0700 (PDT) Message-ID: <4E8F4E5C.5000303@gmail.com> Date: Sat, 08 Oct 2011 08:09:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-ietf-idr-flow-spec-v6.all@tools.ietf.org References: <20111007132957.17302.73174.idtracker@ietfa.amsl.com> In-Reply-To: <20111007132957.17302.73174.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 07 Oct 2011 12:19:04 -0700 Cc: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-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: Fri, 07 Oct 2011 19:06:13 -0000 Hi, My comments below don't seem to have been addresed. draft-ietf-6man-flow-3697bis is now in the RFC Editor queue, by the way. Regards Brian Carpenter -------- Original Message -------- Subject: Re: I-D Action: draft-ietf-idr-flow-spec-v6-00.txt Date: Wed, 15 Jun 2011 01:54:04 +1200 From: Brian E Carpenter Organization: University of Auckland To: draft-ietf-idr-flow-spec-v6.all@tools.ietf.org References: <20110608204732.21837.12076.idtracker@ietfa.amsl.com> Hi, I have a couple of concerns about this draft. > Type 13 - Flow Label - New type > > Encoding: > > Contains a set of {operator, value} pairs that are used to match > the 20-bit Flow Label field [RFC2460].The operator byte is encoded > as specified in the component type 3 of [RFC5575]. One point is that RFC 2460 really doesn't specify anything about the flow label except where it sits in the IPv6 header. The current spec is RFC 3697, but that is close to being replaced by draft-ietf-6man-flow-3697bis. However, that describes a stateless model where there is no need for flow signaling. So, I have no idea what this new type is good for. If there is no use case, why define it? At the very least, there should be a pointer to 3697bis. > Traffic Marking: The traffic marking extended community instructs a > system to modify the Traffic Class bits of a transiting IPv6 packet > to the corresponding value. This extended community is encoded as a > sequence of 5 zero bytes followed by the 8 bit Traffic Class value > encoded in the 6th byte. This breaks ECN. You must only touch the 6 DSCP bits, according to RFC 2474. (That would also be true for IPv4.) Of course there should be a reference to RFC 2474 too. Regards Brian Carpenter From internet-drafts@ietf.org Fri Oct 7 14:08:20 2011 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 A460621F8BEB; Fri, 7 Oct 2011 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 UjnSAmW6Y7w3; Fri, 7 Oct 2011 14:08:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C379521F8BAD; Fri, 7 Oct 2011 14:08:19 -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: 3.60 Message-ID: <20111007210819.694.34440.idtracker@ietfa.amsl.com> Date: Fri, 07 Oct 2011 14:08:19 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-deprecate-as-sets-06.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, 07 Oct 2011 21:08:20 -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 : Recommendation for Not Using AS_SET and AS_CONFED_SET in= BGP Author(s) : Warren Kumari Kotikalapudi Sriram Filename : draft-ietf-idr-deprecate-as-sets-06.txt Pages : 6 Date : 2011-10-07 This document recommends against the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of the BGP protocol and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-06.txt From ietfc@btconnect.com Sat Oct 8 01:34:30 2011 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 8E52F21F8B36 for ; Sat, 8 Oct 2011 01:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 PuGlM0oDOqUY for ; Sat, 8 Oct 2011 01:34:30 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id B18F421F877F for ; Sat, 8 Oct 2011 01:34:29 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2beaomr06.btconnect.com with SMTP id EWL62417; Sat, 08 Oct 2011 09:37:44 +0100 (BST) Message-ID: <009c01cc858c$86422820$4001a8c0@gateway.2wire.net> From: "t.petch" Cc: References: <20111007210819.694.34440.idtracker@ietfa.amsl.com> Date: Sat, 8 Oct 2011 09:33:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4E900BD7.00AC, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.8.74814:17:7.586, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, MISSING_HEADERS, __ANY_URI, __CP_URI_IN_BODY, BODY_SIZE_1700_1799, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, __PHISH_SPEAR_STRUCTURE_1, RDNS_SUSP, BODY_SIZE_2000_LESS, __PHISH_SPEAR_STRUCTURE_2, BODY_SIZE_7000_LESS, TO_MALFORMED X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4E900BD8.003A,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as-sets-06.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: Sat, 08 Oct 2011 08:34:30 -0000 After all our discussions about 'deprecates', the IESG have changed it to 'recommends against'; I shall have to remember that one for next time:-) Tom Petch ----- Original Message ----- From: To: Cc: Sent: Friday, October 07, 2011 11:08 PM Subject: [Idr] I-D Action: draft-ietf-idr-deprecate-as-sets-06.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > Title : Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP > Author(s) : Warren Kumari > Kotikalapudi Sriram > Filename : draft-ietf-idr-deprecate-as-sets-06.txt > Pages : 6 > Date : 2011-10-07 > > This document recommends against the use of the AS_SET and > AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to > simplify the design and implementation of the BGP protocol and to > make the semantics of the originator of a route more clear. This > will also simplify the design, implementation and deployment of > ongoing work in the Secure Inter-Domain Routing Working Group. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-06.txt > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From brian.e.carpenter@gmail.com Sun Oct 9 12:34:03 2011 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 60B3021F8AE1 for ; Sun, 9 Oct 2011 12:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.74 X-Spam-Level: X-Spam-Status: No, score=-101.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 ZXxEWyKF7YSH for ; Sun, 9 Oct 2011 12:34:02 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDF321F8A69 for ; Sun, 9 Oct 2011 12:34:02 -0700 (PDT) Received: by bkaq10 with SMTP id q10so8310489bka.31 for ; Sun, 09 Oct 2011 12:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GogP3UmcQBC1bD7LqZxTV9RiJsO3zViuXdbrElf8lV0=; b=lJ+6Q88JdbZn/gFOXXia0j2yi8lwJQi197ZT5nwjPaKKFN2WMWMPYl/erpybdImlqf bBqMhmHKS+LyoprI6dAYx1Jn+7QP8+lGZDWICBNxR6N1QcYuahymGbuNXrE//9JqR0GP 9HsYi9QN4EVJ+RjDS3c8q1QGPvs9tUKtdPBkI= Received: by 10.223.16.76 with SMTP id n12mr6982510faa.25.1318188840042; Sun, 09 Oct 2011 12:34:00 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n18sm26983926fah.2.2011.10.09.12.33.56 (version=SSLv3 cipher=OTHER); Sun, 09 Oct 2011 12:33:59 -0700 (PDT) Message-ID: <4E91F718.5000909@gmail.com> Date: Mon, 10 Oct 2011 08:33:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: robert@raszuk.net References: <20111007132957.17302.73174.idtracker@ietfa.amsl.com> <4E8F4E5C.5000303@gmail.com> <4E903EAF.4020302@raszuk.net> In-Reply-To: <4E903EAF.4020302@raszuk.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, draft-ietf-idr-flow-spec-v6.all@tools.ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-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: Sun, 09 Oct 2011 19:34:03 -0000 Hi Robert, On 2011-10-09 01:14, Robert Raszuk wrote: > Hi Brian, > > Thank you for your comments. Indeed I have not received the former email > ... sending any comment to draft-ietf-idr-flow-spec-v6.all list is very > unreliable for two reasons ... we all use mail filters and this may not > made it to idr folder .. Well, this is an IETF de facto standard mechanism so I think people's filter rules should be adapted... > mail alias expands to email address which may > have been already obsoleted (job transfer) and most employees at least > in California do not provide fwd facilities nor mail reject message - it > just goes to /dev/null. If the email address is obsolete, that will happen anyway, since the alias is extracted automatically from the draft and other IETF sources, which is where I would look for the addresses if entering them manually. > Now let me address your comments: > >>> Type 13 - Flow Label - New type > > It is there for compliance with base IPv6 RFC. Even if we see no use of > that today when one extends any protocol it seems worthwhile to be > prepared to match on any field IPv6 address may carry in the future > without describing the applications behind it. We are not creating new > protocol here .. we are just extending flow spec encoding to accommodate > what IPv6 header authors had in mind. > > However I have no problem in providing the use case example of > draft-ietf-6man-flow-3697bis if you consider this as useful. 3697bis is not a use case - it is a standards track update of 2460. I think that adding a normative reference to 3697bis is necessary and sufficient; since it's already in the RFC Editor queue, it will be published before your draft anyway. >>> Traffic Marking: >> >> This breaks ECN. You must only touch the 6 DSCP bits, according to >> RFC 2474. (That would also be true for IPv4.) Of course there should >> be a reference to RFC 2474 too. > > Excellent point- thank you very much for catching it. I have reworded > this section to the below: > > Traffic Marking: The traffic marking extended community instructs a > system to modify first 6 bits of Traffic Class field as (recommended > by RFC2472) of a transiting IPv6 packet to the corresponding > value. This extended community is encoded as a sequence of 42 zero > bits followed by the 6 bits overwriting DSCP portion of Traffic > Class value. s/2472/2474/ Otherwise this looks fine. Thanks Brian > > Let me know if this addresses yr points before I republish. RFC2472 will > be also added as normative reference while draft-ietf-6man-flow-3697bis > as an informative one. > > Many thx and apologies for missing your first email, > R. > >> Hi, >> >> My comments below don't seem to have been addresed. >> draft-ietf-6man-flow-3697bis is now in the RFC Editor queue, by the way. >> >> Regards >> Brian Carpenter >> >> >> -------- Original Message -------- >> Subject: Re: I-D Action: draft-ietf-idr-flow-spec-v6-00.txt >> Date: Wed, 15 Jun 2011 01:54:04 +1200 >> From: Brian E Carpenter >> Organization: University of Auckland >> To: draft-ietf-idr-flow-spec-v6.all@tools.ietf.org >> References:<20110608204732.21837.12076.idtracker@ietfa.amsl.com> >> >> Hi, >> >> I have a couple of concerns about this draft. >> >>> Type 13 - Flow Label - New type >>> >>> Encoding: >>> >>> Contains a set of {operator, value} pairs that are used to match >>> the 20-bit Flow Label field [RFC2460].The operator byte is >>> encoded >>> as specified in the component type 3 of [RFC5575]. >> >> One point is that RFC 2460 really doesn't specify anything about the flow >> label except where it sits in the IPv6 header. The current spec is RFC >> 3697, >> but that is close to being replaced by draft-ietf-6man-flow-3697bis. >> However, that describes a stateless model where there is no need for >> flow signaling. >> >> So, I have no idea what this new type is good for. If there is no use >> case, >> why define it? At the very least, there should be a pointer to 3697bis. >> >>> Traffic Marking: The traffic marking extended community instructs a >>> system to modify the Traffic Class bits of a transiting IPv6 packet >>> to the corresponding value. This extended community is encoded as a >>> sequence of 5 zero bytes followed by the 8 bit Traffic Class value >>> encoded in the 6th byte. >> >> This breaks ECN. You must only touch the 6 DSCP bits, according to >> RFC 2474. (That would also be true for IPv4.) Of course there should be >> a reference to RFC 2474 too. >> >> Regards >> Brian Carpenter >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> > > From randy@psg.com Mon Oct 10 04:59:54 2011 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 5999C21F8B8E for ; Mon, 10 Oct 2011 04:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 UJDIOgCmkk58 for ; Mon, 10 Oct 2011 04:59:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6DD21F8B8A for ; Mon, 10 Oct 2011 04:59:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RDEWP-0009wD-0q for idr@ietf.org; Mon, 10 Oct 2011 11:59:53 +0000 Date: Mon, 10 Oct 2011 07:59:53 -0400 Message-ID: From: Randy Bush To: IETF IDR User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [Idr] draft-ietf-idr-bgp-extended-messages-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: Mon, 10 Oct 2011 11:59:54 -0000 could the chairs please process($subject)++ thanks randy From iesg-secretary@ietf.org Mon Oct 10 09:06:37 2011 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 39A6821F8AC3; Mon, 10 Oct 2011 09:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, 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 DwAEFWtrcgDx; Mon, 10 Oct 2011 09:06:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC0521F8AF3; Mon, 10 Oct 2011 09:06:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111010160636.16168.55257.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2011 09:06:36 -0700 Cc: idr mailing list , idr chair , RFC Editor Subject: [Idr] Protocol Action: 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' to BCP (draft-ietf-idr-deprecate-as-sets-06.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, 10 Oct 2011 16:06:37 -0000 The IESG has approved the following document: - 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' (draft-ietf-idr-deprecate-as-sets-06.txt) as a BCP 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-deprecate-as-sets/ Technical Summary This document provides advice to operators. It deprecates the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of the BGP protocol and to make the semantics of the originator of a route more clear. Working Group Summary This document was adopted as a WG item on Oct 25th, 2010. There was an initial WGLC that concluded on April 13th, 2010. Comments from the initial WGLC were integrated and a second WGLC held, which concluded on May17, 2011. Document Quality This note provides advice to operators proposing that they cease using a current BGP protocol feature. Personnel John Scudder (jgs@juniper.net) is the document shepherd. Stewart Bryant (stbryant@cisco.com) is the responsible AD. RFC Editor Note There is no RFC2119 language used in the draft. Please remove section 2 - the RFC2119 section and the RFC2119 reference. From danny@tcb.net Mon Oct 10 11:46:26 2011 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 F355A21F8BE7; Mon, 10 Oct 2011 11:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 gbafcIwJM8-8; Mon, 10 Oct 2011 11:46:25 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3447E21F84D8; Mon, 10 Oct 2011 11:46:18 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP; Mon, 10 Oct 2011 11:46:24 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p9AIjwQa018364; Mon, 10 Oct 2011 14:45:58 -0400 Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com ([10.100.0.219]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Oct 2011 14:45:58 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <20111010160636.16168.55257.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2011 14:45:57 -0400 Content-Transfer-Encoding: 7bit Message-Id: <6D402923-AA10-4EA6-96DC-D88D8E935041@tcb.net> References: <20111010160636.16168.55257.idtracker@ietfa.amsl.com> To: The IESG , idr chair X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 Oct 2011 18:45:58.0051 (UTC) FILETIME=[D96EBF30:01CC877C] Cc: idr mailing list , RFC Editor Subject: Re: [Idr] Protocol Action: 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' to BCP (draft-ietf-idr-deprecate-as-sets-06.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, 10 Oct 2011 18:46:26 -0000 Can someone clue me in as to when the status of this changed from Informational to BCP, in particular since this occurred after the IETF last call said intended publication was Informational? Also, what the implication of this might be on updating RFC 5065, RFC 4271, etc.., as it "recommends against" standardized protocol elements and doesn't contain RFC 2119 language. The IESG comments discuss this as well, and I brought it up on the mailing list quite a while ago when asking about expressly about intended status. In general, I don't have a problem with this being BCP if the wording is cleaned up, but it certainly was not posited as BCP in WG or IETF last call or discussed in the WG to that effect with any response. -danny On Oct 10, 2011, at 12:06 PM, The IESG wrote: > The IESG has approved the following document: > - 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' > (draft-ietf-idr-deprecate-as-sets-06.txt) as a BCP > > 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-deprecate-as-sets/ > > > > > Technical Summary > > This document provides advice to operators. It deprecates > the use of the AS_SET and AS_CONFED_SET types of > the AS_PATH in BGPv4. This is done to simplify the > design and implementation of the BGP protocol and to make > the semantics of the originator of a route more clear. > > Working Group Summary > > This document was adopted as a WG item on > Oct 25th, 2010. There was an initial WGLC > that concluded on April 13th, 2010. Comments > from the initial WGLC were integrated and a > second WGLC held, which concluded on May17, 2011. > > Document Quality > > This note provides advice to operators proposing that > they cease using a current BGP protocol feature. > > Personnel > > John Scudder (jgs@juniper.net) is the document shepherd. > Stewart Bryant (stbryant@cisco.com) is the responsible AD. > > RFC Editor Note > > There is no RFC2119 language used in the draft. > > Please remove section 2 - the RFC2119 section and the > RFC2119 reference. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From christopher.morrow@gmail.com Mon Oct 10 11:59:02 2011 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 7590221F8BFB; Mon, 10 Oct 2011 11:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 B-AlpmUklbsz; Mon, 10 Oct 2011 11:59:01 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C74CC21F8BDE; Mon, 10 Oct 2011 11:59:01 -0700 (PDT) Received: by iaby26 with SMTP id y26so9494525iab.31 for ; Mon, 10 Oct 2011 11:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5UYsIdqXLU1fiqgimBrQUnbV+/RtPILbQJMeJHokvVo=; b=uxgSW9mOeGCMpQWDp7QhxLJXMc565YE2V3HJ2BR+QLswbDkO2tQvnqL96p2UaR2Aof PUErNx96m6IHdNbSBH0mS6nF9/wgr4RADE/JPIY1VKttD1cc772EV/gvmL/JPKxkQFZS 214AabqMeHemX9aIoNR/pMI5C9UeYc1LzN1Co= MIME-Version: 1.0 Received: by 10.231.6.102 with SMTP id 38mr2887389iby.62.1318273141310; Mon, 10 Oct 2011 11:59:01 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.59.206 with HTTP; Mon, 10 Oct 2011 11:59:01 -0700 (PDT) In-Reply-To: <6D402923-AA10-4EA6-96DC-D88D8E935041@tcb.net> References: <20111010160636.16168.55257.idtracker@ietfa.amsl.com> <6D402923-AA10-4EA6-96DC-D88D8E935041@tcb.net> Date: Mon, 10 Oct 2011 14:59:01 -0400 X-Google-Sender-Auth: yd6TB3GLlmGiWtg085fED1bpfCM Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr mailing list , idr chair , The IESG , RFC Editor Subject: Re: [Idr] Protocol Action: 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' to BCP (draft-ietf-idr-deprecate-as-sets-06.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, 10 Oct 2011 18:59:02 -0000 On Mon, Oct 10, 2011 at 2:45 PM, Danny McPherson wrote: > > Can someone clue me in as to when the status of this changed > from Informational to BCP, in particular since this occurred > after the IETF last call said intended publication was > Informational? I had thought (as had Warren when we last chatted ~20 mins ago) that it was supposed to be Informational. (as one data point in the wind) -chris > Also, what the implication of this might be on updating RFC 5065, > RFC 4271, etc.., as it "recommends against" standardized protocol > elements and doesn't contain RFC 2119 language. =A0The IESG comments > discuss this as well, and I brought it up on the mailing list quite > a while ago when asking about expressly about intended status. > > In general, I don't have a problem with this being BCP if the wording > is cleaned up, but it certainly was not posited as BCP in WG or IETF > last call or discussed in the WG to that effect with any response. > > -danny > > > On Oct 10, 2011, at 12:06 PM, The IESG wrote: > >> The IESG has approved the following document: >> - 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' >> =A0(draft-ietf-idr-deprecate-as-sets-06.txt) as a BCP >> >> 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-deprecate-as-sets/ >> >> >> >> >> Technical Summary >> >> This document provides advice to operators. It deprecates >> the use of the AS_SET and AS_CONFED_SET types of >> the AS_PATH in BGPv4. This is done to simplify the >> design and implementation of the BGP protocol and to make >> the semantics of the originator of a route more clear. >> >> Working Group Summary >> >> This document was adopted as a WG item on >> Oct 25th, 2010. There was an initial WGLC >> that concluded on April 13th, 2010. Comments >> from the initial WGLC were integrated and a >> second WGLC held, which concluded on May17, 2011. >> >> Document Quality >> >> This note provides advice to operators proposing that >> they cease using a current BGP protocol feature. >> >> Personnel >> >> John Scudder (jgs@juniper.net) is the document shepherd. >> Stewart Bryant (stbryant@cisco.com) is the responsible AD. >> >> RFC Editor Note >> >> There is no RFC2119 language used in the draft. >> >> Please remove section 2 - the RFC2119 section and the >> RFC2119 reference. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From skh@ndzh.com Mon Oct 10 13:06:16 2011 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 F062921F8C09 for ; Mon, 10 Oct 2011 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.006 X-Spam-Level: * X-Spam-Status: No, score=1.006 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFeArwSaDppL for ; Mon, 10 Oct 2011 13:06:16 -0700 (PDT) Received: from hickoryhill-consulting.com (63-208-161-201.digitalrealm.net [63.208.161.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0B60421F8BE7 for ; Mon, 10 Oct 2011 13:06:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.187.221.107; Received: from SKHPERSONALLT (unverified [199.187.221.107]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 2738622-1945496 for multiple; Mon, 10 Oct 2011 16:06:12 -0400 From: "Susan Hares" To: "'Randy Bush'" , "'IETF IDR'" References: In-Reply-To: Date: Mon, 10 Oct 2011 16:06:26 -0400 Message-ID: <00db01cc8788$1783aff0$468b0fd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcyHRCJO2RuTLYEyShexkdowFavQHgAQUq3w X-Authenticated-User: skh@ndzh.com Subject: Re: [Idr] draft-ietf-idr-bgp-extended-messages-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: Mon, 10 Oct 2011 20:06:17 -0000 Is process ($subject) add to WG charter, if so pending. Will get update. (pause) Process ($subject) final LC needs two implementation. If people have implementation, please send note to WG chairs. Is process can you file +02 version. Do so. Cheers, Sue Hares -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Monday, October 10, 2011 8:00 AM To: IETF IDR Subject: [Idr] draft-ietf-idr-bgp-extended-messages-01.txt could the chairs please process($subject)++ thanks randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From wwwrun@rfc-editor.org Tue Oct 11 01:26:16 2011 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 25FBB21F8C0D for ; Tue, 11 Oct 2011 01:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=0.317, 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 V2Uk7KNE3Dy2 for ; Tue, 11 Oct 2011 01:26:15 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BE95421F8B39 for ; Tue, 11 Oct 2011 01:26:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5835598C274; Tue, 11 Oct 2011 01:26:15 -0700 (PDT) To: enkechen@cisco.com, jenny@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20111011082615.5835598C274@rfc-editor.org> Date: Tue, 11 Oct 2011 01:26:15 -0700 (PDT) Cc: bortzmeyer+rfceditor@nic.fr, rfc-editor@rfc-editor.org, idr@ietf.org Subject: [Idr] [Editorial Errata Reported] RFC6286 (2990) 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, 11 Oct 2011 08:26:16 -0000 The following errata report has been submitted for RFC6286, "Autonomous-System-Wide Unique BGP Identifier for BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6286&eid=2990 -------------------------------------- Type: Editorial Reported by: Stéphane Bortzmeyer Section: 3 Original Text ------------- In the AGGREAGTOR attribute of a route Corrected Text -------------- n the AGGREGATOR attribute of a route Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6286 (draft-ietf-idr-bgp-identifier-14) -------------------------------------- Title : Autonomous-System-Wide Unique BGP Identifier for BGP-4 Publication Date : June 2011 Author(s) : E. Chen, J. Yuan Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From ietfc@btconnect.com Tue Oct 11 03:32:57 2011 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 C6EAF21F8D7F for ; Tue, 11 Oct 2011 03:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 fWSRv0GJp1R7 for ; Tue, 11 Oct 2011 03:32:57 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by ietfa.amsl.com (Postfix) with ESMTP id 991A421F8D69 for ; Tue, 11 Oct 2011 03:32:56 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2beaomr07.btconnect.com with SMTP id ESG61320; Tue, 11 Oct 2011 11:32:28 +0100 (BST) Message-ID: <00b801cc87f8$0a691600$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Christopher Morrow" , "Danny McPherson" References: <20111010160636.16168.55257.idtracker@ietfa.amsl.com><6D402923-AA10-4EA6-96DC-D88D8E935041@tcb.net> Date: Tue, 11 Oct 2011 11:27:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4E941B3A.0047, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.10.11.93314:17:7.944, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __CP_URI_IN_BODY, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4E941B3E.0118,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: idr mailing list , idr chair Subject: Re: [Idr] Protocol Action: 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' to BCP (draft-ietf-idr-deprecate-as-sets-06.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, 11 Oct 2011 10:32:57 -0000 The status changed in -05 27Jul2011 following a request from Stewart Bryant 15Jul2011 ie during AD Review prior to IETF Last Call. Tom Petch ----- Original Message ----- From: "Christopher Morrow" To: "Danny McPherson" Cc: "idr mailing list" ; "idr chair" ; "The IESG" ; "RFC Editor" Sent: Monday, October 10, 2011 8:59 PM Subject: Re: [Idr] Protocol Action: 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' to BCP (draft-ietf-idr-deprecate-as-sets-06.txt) On Mon, Oct 10, 2011 at 2:45 PM, Danny McPherson wrote: > > Can someone clue me in as to when the status of this changed > from Informational to BCP, in particular since this occurred > after the IETF last call said intended publication was > Informational? I had thought (as had Warren when we last chatted ~20 mins ago) that it was supposed to be Informational. (as one data point in the wind) -chris > Also, what the implication of this might be on updating RFC 5065, > RFC 4271, etc.., as it "recommends against" standardized protocol > elements and doesn't contain RFC 2119 language. The IESG comments > discuss this as well, and I brought it up on the mailing list quite > a while ago when asking about expressly about intended status. > > In general, I don't have a problem with this being BCP if the wording > is cleaned up, but it certainly was not posited as BCP in WG or IETF > last call or discussed in the WG to that effect with any response. > > -danny > > > On Oct 10, 2011, at 12:06 PM, The IESG wrote: > >> The IESG has approved the following document: >> - 'Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP' >> (draft-ietf-idr-deprecate-as-sets-06.txt) as a BCP >> >> 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-deprecate-as-sets/ >> >> >> >> >> Technical Summary >> >> This document provides advice to operators. It deprecates >> the use of the AS_SET and AS_CONFED_SET types of >> the AS_PATH in BGPv4. This is done to simplify the >> design and implementation of the BGP protocol and to make >> the semantics of the originator of a route more clear. >> >> Working Group Summary >> >> This document was adopted as a WG item on >> Oct 25th, 2010. There was an initial WGLC >> that concluded on April 13th, 2010. Comments >> from the initial WGLC were integrated and a >> second WGLC held, which concluded on May17, 2011. >> >> Document Quality >> >> This note provides advice to operators proposing that >> they cease using a current BGP protocol feature. >> >> Personnel >> >> John Scudder (jgs@juniper.net) is the document shepherd. >> Stewart Bryant (stbryant@cisco.com) is the responsible AD. >> >> RFC Editor Note >> >> There is no RFC2119 language used in the draft. >> >> Please remove section 2 - the RFC2119 section and the >> RFC2119 reference. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ahagens@amsl.com Tue Oct 11 14:22:27 2011 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 2797721F8DD7 for ; Tue, 11 Oct 2011 14:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BQ13H7H9y5p for ; Tue, 11 Oct 2011 14:22:26 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id A42B121F8DDC for ; Tue, 11 Oct 2011 14:22:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 441D13A200C; Tue, 11 Oct 2011 14:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9s2F7CGPj86; Tue, 11 Oct 2011 14:22:26 -0700 (PDT) Received: from [192.168.1.106] (c-76-30-69-22.hsd1.tx.comcast.net [76.30.69.22]) by c1a.amsl.com (Postfix) with ESMTPSA id 0EF0C1C38095; Tue, 11 Oct 2011 14:22:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Alice Hagens In-Reply-To: <20111011134114.GA13958@nic.fr> Date: Tue, 11 Oct 2011 17:22:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66C9C2B7-AF86-4AE5-A739-F1C5E146ED12@amsl.com> References: <20111011082615.5835598C274@rfc-editor.org> <1527269638-1318340138-cardhu_decombobulator_blackberry.rim.net-1931111644-@b15.c6.bise6.blackberry> <20111011134114.GA13958@nic.fr> To: shares@ndzh.com, Stephane Bortzmeyer X-Mailer: Apple Mail (2.1084) Cc: "idr@ietf. org" , RFC Editor Subject: Re: [Idr] [Editorial Errata Reported] RFC6286 (2990) 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, 11 Oct 2011 21:22:27 -0000 FYI, the report has been corrected to "In" as intended: http://www.rfc-editor.org/errata_search.php?rfc=3D6286&eid=3D2990 Thank you. RFC Editor/ah On Oct 11, 2011, at 9:41 AM, Stephane Bortzmeyer wrote: > On Tue, Oct 11, 2011 at 01:35:39PM +0000, > shares@ndzh.com wrote=20 > a message of 33 lines which said: >=20 >> Please confirm firs word in errata corrected text is "'in". >=20 > Yes. Sorry. An error in the errata :-) >=20 >=20 On Oct 11, 2011, at 4:26 AM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC6286, > "Autonomous-System-Wide Unique BGP Identifier for BGP-4". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6286&eid=3D2990 >=20 > -------------------------------------- > Type: Editorial > Reported by: St=E9phane Bortzmeyer >=20 > Section: 3 >=20 > Original Text > ------------- > In the AGGREAGTOR attribute of a route >=20 > Corrected Text > -------------- > n the AGGREGATOR attribute of a route >=20 >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6286 (draft-ietf-idr-bgp-identifier-14) > -------------------------------------- > Title : Autonomous-System-Wide Unique BGP Identifier for = BGP-4 > Publication Date : June 2011 > Author(s) : E. Chen, J. Yuan > Category : PROPOSED STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 From jgs@juniper.net Thu Oct 13 09:41:29 2011 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 DC69021F86A6 for ; Thu, 13 Oct 2011 09:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id locXREQj-cM5 for ; Thu, 13 Oct 2011 09:41:29 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5C121F8677 for ; Thu, 13 Oct 2011 09:41:28 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP; Thu, 13 Oct 2011 09:41:29 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 13 Oct 2011 09:38:34 -0700 From: John Scudder To: "Stewart Bryant (stbryant)" Date: Thu, 13 Oct 2011 09:38:33 -0700 Thread-Topic: [Idr] [Editorial Errata Reported] RFC6286 (2990) Thread-Index: AcyJxoyr3/oY2IH+SFyOvUH9u6xFWg== Message-ID: <8F3A4088-02A0-4079-9AD3-F6D9934B5A7D@juniper.net> References: <20111011082615.5835598C274@rfc-editor.org> <1527269638-1318340138-cardhu_decombobulator_blackberry.rim.net-1931111644-@b15.c6.bise6.blackberry> <20111011134114.GA13958@nic.fr> <66C9C2B7-AF86-4AE5-A739-F1C5E146ED12@amsl.com> In-Reply-To: <66C9C2B7-AF86-4AE5-A739-F1C5E146ED12@amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf. org" , Stephane Bortzmeyer , Hares Susan , RFC Editor Subject: Re: [Idr] [Editorial Errata Reported] RFC6286 (2990) 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, 13 Oct 2011 16:41:30 -0000 Stewart, can we move this to "verified" please? It's a noncontroversial ty= po correction. Thanks, --John On Oct 11, 2011, at 5:22 PM, Alice Hagens wrote: > FYI, the report has been corrected to "In" as intended: > http://www.rfc-editor.org/errata_search.php?rfc=3D6286&eid=3D2990 >=20 > Thank you. > RFC Editor/ah >=20 > On Oct 11, 2011, at 9:41 AM, Stephane Bortzmeyer wrote: >=20 >> On Tue, Oct 11, 2011 at 01:35:39PM +0000, >> shares@ndzh.com wrote=20 >> a message of 33 lines which said: >>=20 >>> Please confirm firs word in errata corrected text is "'in". >>=20 >> Yes. Sorry. An error in the errata :-) >>=20 >>=20 >=20 > On Oct 11, 2011, at 4:26 AM, RFC Errata System wrote: >=20 >>=20 >> The following errata report has been submitted for RFC6286, >> "Autonomous-System-Wide Unique BGP Identifier for BGP-4". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6286&eid=3D2990 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: St=E9phane Bortzmeyer >>=20 >> Section: 3 >>=20 >> Original Text >> ------------- >> In the AGGREAGTOR attribute of a route >>=20 >> Corrected Text >> -------------- >> n the AGGREGATOR attribute of a route >>=20 >>=20 >> Notes >> ----- >>=20 >>=20 >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC6286 (draft-ietf-idr-bgp-identifier-14) >> -------------------------------------- >> Title : Autonomous-System-Wide Unique BGP Identifier for B= GP-4 >> Publication Date : June 2011 >> Author(s) : E. Chen, J. Yuan >> Category : PROPOSED STANDARD >> Source : Inter-Domain Routing >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >>=20 >=20 From robert@raszuk.net Fri Oct 21 15:23:54 2011 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 7C62421F8876 for ; Fri, 21 Oct 2011 15:23: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=[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 qCNtxj-n5nYQ for ; Fri, 21 Oct 2011 15:23:54 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id BD91A21F8880 for ; Fri, 21 Oct 2011 15:23:53 -0700 (PDT) Received: (qmail 536 invoked by uid 399); 21 Oct 2011 22:23:52 -0000 Received: from unknown (HELO ?216.69.69.179?) (216.69.69.179) by mail37.opentransfer.com with SMTP; 21 Oct 2011 22:23:52 -0000 Message-ID: <4EA1F0FB.3090100@raszuk.net> Date: Sat, 22 Oct 2011 00:23:55 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "idr@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 22:23:54 -0000 Hi, I have read the draft and have one question and one observation. Question: What is the point of defining DO_NOT_PERSIST community ? In other words why not having PERSIST community set would not mean the same as having path marked with DO_NOT_PERSIST. Observation: I found the below statement in section 4.2: o Forwarding must ensure that the Next Hop to a "stale" route is viable. Of course I agree. But since we stating obvious in the forwarding section I think it would be good to explicitly also state this in the best path selection that next hop to STALE best path must be valid. However sessions especially those between loopbacks do not go down for no reason. Most likely there is network problem which may have caused those sessions to go down. It is therefor likely that LDP session went also down between any of the LSRs in the data path and that in spite of having the paths in BGP and next hops in IGP the LSP required for both quoted L2/L3VPN applications is broken. That may particularly happen when network chooses to use independent control mode for label allocation. I would suggest to at least add the recommendation statement to the document that during best path selection especially for stale paths a validity of required forwarding paradigm to next hop of stale paths should be verified. For example using techniques as described in: draft-ietf-idr-bgp-bestpath-selection-criteria Best regards, R. From robert@raszuk.net Sun Oct 23 14:32:24 2011 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 2B8C121F8AAA for ; Sun, 23 Oct 2011 14:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619] 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 i2NwPqsYfPT2 for ; Sun, 23 Oct 2011 14:32:23 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 52EFE21F8AA9 for ; Sun, 23 Oct 2011 14:32:22 -0700 (PDT) Received: (qmail 13944 invoked by uid 399); 23 Oct 2011 21:32:21 -0000 Received: from unknown (HELO ?10.0.1.5?) (216.31.254.135) by mail37.opentransfer.com with SMTP; 23 Oct 2011 21:32:21 -0000 Message-ID: <4EA487E4.2040201@raszuk.net> Date: Sun, 23 Oct 2011 23:32:20 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "idr@ietf.org List" References: <4EA1F0FB.3090100@raszuk.net> In-Reply-To: <4EA1F0FB.3090100@raszuk.net> X-Forwarded-Message-Id: <4EA1F0FB.3090100@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 21:32:24 -0000 Authors, Actually when discussing this draft a new concern surfaced which I would like to get your answer on. The draft in section 4.2 says as one of the forwarding rules: o Forwarding to a "stale" route is only used if there are no other paths available to that route. In other words an active path always wins regardless of path selection. "Stale" state is always considered to be less preferred when compared with an active path. In the light of the above rule let's consider a very simple case of dual PE attached site of L3VPN service. Two CEs would inject into their IBGP mesh routes to the remote destination: one marked as STALE and one not marked at all. (Each CE is connected to different PE and each PE RT imports only a single route to a remote hub headquarter to support geographic load balancing). Let me illustrate: VPN Customer HUB PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | | 1| |10 | | R1 ------ R2 1 CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 and R2-CE2 is 10. Prefix X is advertised by remote hub in the given VPN such that PE1 vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has X via PE4. Let's assume EBGP sessions PE3 to HUB went down, but ethernet link is up, next hop is in the RIB while data plane is gone. Assume no data plane real validation too. /* That is why in my former message I suggested that data plane validation would be necessary */. R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands STALE so selects in his forwarding table path via CE2. R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not understand STALE, never was upgraded to support the forwarding rule stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). R1--R2 produce data plane loop as long as STALE paths are present in the system. Quite fun to troubleshoot too as the issue of PE3 injecting such STALE paths may be on the opposite site of the world. The issue occurs when some routers within the customer site will be able to recognize STALE transitive community and prefer non stale paths in their forwarding planes (or BGP planes for that matter) while others will not as well as when both stale and non stale paths will be present. Question 1: How do you prevent forwarding loop in such case ? Question 2: How do you prevent forwarding loop in the case when customer would have backup connectivity to his sites or connectivity via different VPN provider yet routers in his site only partially understand the STALE community and only partially follow the forwarding rules ? In general as the rule is about mandating some particular order of path forwarding selection what is the mechanism in distributed systems like today's routing to be able to achieve any assurance that such rule is active and enforced across _all_ routers behind EBGP PE-CE L3VPN boundaries in customer sites ? Best regards, R. -------- Original Message -------- Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 +0200 From: Robert Raszuk Reply-To: robert@raszuk.net To: idr@ietf.org List Hi, I have read the draft and have one question and one observation. Question: What is the point of defining DO_NOT_PERSIST community ? In other words why not having PERSIST community set would not mean the same as having path marked with DO_NOT_PERSIST. Observation: I found the below statement in section 4.2: o Forwarding must ensure that the Next Hop to a "stale" route is viable. Of course I agree. But since we stating obvious in the forwarding section I think it would be good to explicitly also state this in the best path selection that next hop to STALE best path must be valid. However sessions especially those between loopbacks do not go down for no reason. Most likely there is network problem which may have caused those sessions to go down. It is therefor likely that LDP session went also down between any of the LSRs in the data path and that in spite of having the paths in BGP and next hops in IGP the LSP required for both quoted L2/L3VPN applications is broken. That may particularly happen when network chooses to use independent control mode for label allocation. I would suggest to at least add the recommendation statement to the document that during best path selection especially for stale paths a validity of required forwarding paradigm to next hop of stale paths should be verified. For example using techniques as described in: draft-ietf-idr-bgp-bestpath-selection-criteria Best regards, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Mon Oct 24 08:13:12 2011 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 47F5A21F8E4B for ; Mon, 24 Oct 2011 08:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 5LOkb-hZCN4a for ; Mon, 24 Oct 2011 08:13:11 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 799B921F8E46 for ; Mon, 24 Oct 2011 08:13:11 -0700 (PDT) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1319469189!45392161!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18686 invoked from network); 24 Oct 2011 15:13:09 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Oct 2011 15:13:09 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9OFDZvb005851; Mon, 24 Oct 2011 11:13:36 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9OFDTKX005655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Oct 2011 11:13:29 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0339.001; Mon, 24 Oct 2011 11:13:01 -0400 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" , "idr@ietf.org List" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMZWLmyFg Date: Mon, 24 Oct 2011 15:13:00 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> In-Reply-To: <4EA1F0FB.3090100@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-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: Mon, 24 Oct 2011 15:13:12 -0000 Robert, Comments In-Line Thanks, Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: Friday, October 21, 2011 6:24 PM To: idr@ietf.org List Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 Hi, I have read the draft and have one question and one observation. Question: What is the point of defining DO_NOT_PERSIST community ? In other words=20 why not having PERSIST community set would not mean the same as having=20 path marked with DO_NOT_PERSIST. Observation: I found the below statement in section 4.2: o Forwarding must ensure that the Next Hop to a "stale" route is viable. Of course I agree. But since we stating obvious in the forwarding=20 section I think it would be good to explicitly also state this in the=20 best path selection that next hop to STALE best path must be valid. However sessions especially those between loopbacks do not go down for=20 no reason. Most likely there is network problem which may have caused=20 those sessions to go down. It is therefor likely that LDP session went=20 also down between any of the LSRs in the data path and that in spite of=20 having the paths in BGP and next hops in IGP the LSP required for both=20 quoted L2/L3VPN applications is broken. That may particularly happen=20 when network chooses to use independent control mode for label allocation. [Jim U>] Why do you believe that? BGP can and does fail independently of th= e underlying LDP session.. I do believe that viability of a data path betwe= en two endpoints should be taken into account when validating paths to NHs = but that effort is clearly a much bigger effort.. This draft would take adv= antage of this mechanism but I am not looking to define that in this draft.= . I would suggest to at least add the recommendation statement to the=20 document that during best path selection especially for stale paths a=20 validity of required forwarding paradigm to next hop of stale paths=20 should be verified. [Jim U>] Why would this not be something that needs to be done as a general= rule for paths.. I mean the underlying LSP could fail independently of BGP= .. If this needs to be done in should be done as a general rule... For example using techniques as described in:=20 draft-ietf-idr-bgp-bestpath-selection-criteria Best regards, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Mon Oct 24 23:15:44 2011 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 F234421F8C0A for ; Mon, 24 Oct 2011 23:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQYFYAKxXD8u for ; Mon, 24 Oct 2011 23:15:43 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id B2E4921F8C09 for ; Mon, 24 Oct 2011 23:15:42 -0700 (PDT) Received: (qmail 25907 invoked by uid 399); 25 Oct 2011 06:15:41 -0000 Received: from unknown (HELO ?192.168.4.68?) (65.91.54.2) by mail37.opentransfer.com with SMTP; 25 Oct 2011 06:15:41 -0000 Message-ID: <4EA6540C.9090100@raszuk.net> Date: Tue, 25 Oct 2011 08:15:40 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EA1F0FB.3090100@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 06:15:44 -0000 Hi Jim, > [Jim U>] Why do you believe that? BGP can > and does fail independently of the underlying LDP session.. I do > believe that viability of a data path between two endpoints should be > taken into account when validating paths to NHs but that effort is > clearly a much bigger effort.. This draft would take advantage of > this mechanism but I am not looking to define that in this draft.. In my opinion there is a need to recognize the difference of possibly locally using a stale path (and that is btw exactly what GR spec does .. except here it would be GR per prefix with longer timer) versus keep advertising paths which may be invalid. > I would suggest to at least add the recommendation statement to the > document that during best path selection especially for stale paths > a validity of required forwarding paradigm to next hop of stale > paths should be verified. [Jim U>] Why would this not be something > that needs to be done as a general rule for paths.. I mean the > underlying LSP could fail independently of BGP.. If this needs to be > done in should be done as a general rule... Respectfully disagree. I am sure you very well know how many customers are relaying on using BGP keepalives to determine PE-CE link up and PE-CE reachability. Recall how many times SP customers including your own customers were asking to reduce holdtime on their ebgp session to 3/9 ... those customers just do not have a better way to determine VPN site reachability. Of course such reduction of keepalives is a bad idea (even if their processing is offloaded or prioritized on main RP) so BFD was invented to address this issue. And either BFD if present or EBGP session up state was _the_only_ probe to determine if CE over frame relay PVC or multiaccess media is live. That is the key difference. So when you drop session you remove prefixes advertised from the site and backup can be activated. Now you are proposing to keep advertising them as STALE which really means MAYBE_REACHABLE. I am not sure why validation of next hop reachability by BFD or even OBJECT_TRACKING or SCRIPT would be at all difficult. Anyway I think this proposal as pointed out in the other email has much bigger deployment issue so I think there is not much point on this validation debate at this point before the loop problem is solved due to inconsistent forwarding plane decisions. Best regards, R. From internet-drafts@ietf.org Tue Oct 25 11:12:43 2011 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 6A8F221F8B8B; Tue, 25 Oct 2011 11:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, 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 cfQlesUfFOdt; Tue, 25 Oct 2011 11:12:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DC221F8B83; Tue, 25 Oct 2011 11:12:42 -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: 3.61 Message-ID: <20111025181242.29707.90844.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 11:12:42 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-optional-transitive-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: Tue, 25 Oct 2011 18:12:43 -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-optional-transitive-04.txt Pages : 10 Date : 2011-10-25 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 optional attributes. Finally, it revises the error handling procedures for several existing attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-optional-transitive-04.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-optional-transitive-04.txt From enkechen@cisco.com Tue Oct 25 11:26:28 2011 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 A649A21F8BF4 for ; Tue, 25 Oct 2011 11:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.001, 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 Pyp1wv05a8zB for ; Tue, 25 Oct 2011 11:26:27 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B78E521F8BE9 for ; Tue, 25 Oct 2011 11:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=2983; q=dns/txt; s=iport; t=1319567187; x=1320776787; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=923QMXbiaoLVZDaObnAF8r3KZ00lAsSSrDHzkJNRuqA=; b=Y/A6l/B4VXXSHBiBsn2p+OntywKycBENu0uJw8uvzOlOaPB9F4FYI4CY ciCq8JN/CZ6rvN5zMfNX4BAhtgl3cA0fqROHnqQWs1ClpCkeDLPj6bR6j u6/c74HA4W6Y5vCufneTfq0uv1K84ZHIapIPFFsxG4nJZNxTZr/TuNUqY E=; X-IronPort-AV: E=Sophos;i="4.69,405,1315180800"; d="scan'208";a="10202703" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 25 Oct 2011 18:26:27 +0000 Received: from enkechen-mac.local ([10.155.34.161]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9PIQRJo004880; Tue, 25 Oct 2011 18:26:27 GMT Message-ID: <4EA6FF90.9020202@cisco.com> Date: Tue, 25 Oct 2011 11:27:28 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: idr@ietf.org References: <20111025181242.29707.90844.idtracker@ietfa.amsl.com> In-Reply-To: <20111025181242.29707.90844.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] I-D Action: draft-ietf-idr-optional-transitive-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: Tue, 25 Oct 2011 18:26:28 -0000 Hi, folks: The draft has been revised extensively as a result of consolidation with draft-chen-ebgp-error-handling-01.txt. Here is a summary of the main changes: o Use "treat-as-withdraw" / "attribute discard" (instead of session reset) whenever possible in order to minimize the impact on routing. o Cover the well-known attributes as well as optional attributes o Specify that errors with the Attribute Flags should be fixed locally o Remove the "Neighbor-Complete flag", and also the check for Partial flag They are no longer needed given our goal of minimizing impact on routing. o Add the following in Operational Considerations: When a malformed attribute is indeed detected over an IBGP session, we recommend that routes with the malformed attribute be identified and traced back to the ingress router in the network where the routes were sourced or received externally, and then a filter be applied on the ingress router to prevent the routes from being sourced or received. Thanks. -- Enke On 10/25/11 11:12 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 : Revised Error Handling for BGP UPDATE Messages > Author(s) : John G. Scudder > Enke Chen > Pradosh Mohapatra > Keyur Patel > Filename : draft-ietf-idr-optional-transitive-04.txt > Pages : 10 > Date : 2011-10-25 > > 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 optional attributes. Finally, it > revises the error handling procedures for several existing > attributes. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-optional-transitive-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-optional-transitive-04.txt > _______________________________________________ > 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 From jgs@juniper.net Tue Oct 25 11:39:43 2011 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 91A8F21F8C68 for ; Tue, 25 Oct 2011 11:39:43 -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 5W1sXCzJ33mn for ; Tue, 25 Oct 2011 11:39:43 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 22A2121F8C67 for ; Tue, 25 Oct 2011 11:39:42 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Tue, 25 Oct 2011 11:39:42 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 25 Oct 2011 11:36:32 -0700 From: John Scudder To: "idr@ietf.org List" Date: Tue, 25 Oct 2011 11:36:32 -0700 Thread-Topic: IETF-82 agenda topics Thread-Index: AcyTRQSOrMBUjqBpTSiUpzuNTs44gg== Message-ID: <83BCCE11-4EB3-4890-B852-CB704AA6DA9F@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Idr] IETF-82 agenda topics 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 Oct 2011 18:39:43 -0000 Folks, We're planning to meet at IETF-82. On the agenda we are scheduled for Tues= day, November 15 09:00 - 11:30. Please forward any IDR agenda items you mi= ght have to Sue and myself. The deadline is November 6 by 13:00 U.S. Easte= rn Time, although earlier is better. If you plan to make a presentation, please keep in mind the IDR tradition, = "no Internet Draft - no time slot". You should also plan to send your slid= es to Sue and me no later than 24 hours prior to the meeting. --John & Sue From internet-drafts@ietf.org Tue Oct 25 16:33:37 2011 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 36F1B11E80FF; Tue, 25 Oct 2011 16:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, 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 XTcMkiftGr81; Tue, 25 Oct 2011 16:33:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C391611E80F9; Tue, 25 Oct 2011 16:33:36 -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: 3.61 Message-ID: <20111025233336.26348.65152.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 16:33:36 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-02.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 Oct 2011 23:33:37 -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 : Dissemination of Flow Specification Rules for IPv6 Author(s) : Robert Raszuk Burjiz Pithawala Danny McPherson Filename : draft-ietf-idr-flow-spec-v6-02.txt Pages : 8 Date : 2011-10-25 Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-v6-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-v6-02.txt From shane@castlepoint.net Tue Oct 25 20:29:44 2011 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 04B3621F8678 for ; Tue, 25 Oct 2011 20:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 y8x7DdHmXQwl for ; Tue, 25 Oct 2011 20:29:43 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 53C3921F84A2 for ; Tue, 25 Oct 2011 20:29:40 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C626A268063; Tue, 25 Oct 2011 21:29:35 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for idr@ietf.org; Tue, 25 Oct 2011 21:29:35 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=64932; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 From: Shane Amante Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2011 21:29:20 -0600 Message-Id: <7D9F12D4-F791-42A0-82CA-788B942A4467@castlepoint.net> To: "idr@ietf.org List" Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [Idr] draft-scudder-idr-ebgp-rr-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 03:29:44 -0000 Hi John, I've read over this draft and have a couple of questions & comments: 1) Is it correct to assume that one use case of this draft is running = EBGP to a Route Reflector as in Inter-AS Option C, where one definitely = wants to avoid changing NEXT_HOP on eBGP learned routes from the = adjacent AS, particularly when the RR's are "Control Plane" only = devices. Would a brief mention of this draft's applicability toward = Inter-AS Option C be helpful? 2) In Section 3, it's difficult to understand the intent of the 2nd = bullet, because it's not using the terminology of RFC 4456: o The speaker SHOULD NOT add a CLUSTER_LIST to EBGP-learned routes when advertising them into IBGP. Specifically, when you say "advertising them into IBGP", do you mean: a) A Non-Client IBGP peer; b) A Client peer; c) Both (a) and (b)? Could you add a few words to the above statement in the draft so it = aligns with terminology in 4456, to avoid any unnecessary confusion? FWIW, I assume you most likely meant (a), which means that a = CLUSTER_LIST would still get added for incoming EBGP routes, by the RR, = when 'reflecting' the route to a client peer in order to preserve the = behavior of Section 8 of RFC 4456, namely avoiding routing information = loops through misconfiguration (of a client)? =20 Thanks, -shane= From ju1738@att.com Wed Oct 26 09:44:39 2011 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 826D921F8B70 for ; Wed, 26 Oct 2011 09:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 nklvSNVKDYVa for ; Wed, 26 Oct 2011 09:44:38 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id A035521F8B6B for ; Wed, 26 Oct 2011 09:44:38 -0700 (PDT) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1319647474!45726389!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11716 invoked from network); 26 Oct 2011 16:44:35 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Oct 2011 16:44:35 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9QGj1qC013602; Wed, 26 Oct 2011 12:45:02 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9QGj1tu013595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Oct 2011 12:45:01 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0339.001; Wed, 26 Oct 2011 12:44:33 -0400 From: "UTTARO, JAMES" To: "robert@raszuk.net" , "idr@ietf.org List" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMZWKuQoAgAQhplA= Date: Wed, 26 Oct 2011 16:44:33 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> In-Reply-To: <4EA487E4.2040201@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.110.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 16:44:39 -0000 Robert, The introduction of this technology needs to be carefully evaluated when b= eing deployed into the network. Your example clearly calls out how a series= of independent design can culminate in incorrect behavior. Certainly the d= eployment of persistence on a router that has interaction with a router tha= t does not needs to be clearly understood by the network designer. The goal= of this draft is to provide a fairly sophisticated tool that will protect = the majority of customers in the event of a catastrophic failure.. The prem= ise being the perfect is not the enemy of the good.. I will add text in the= deployment considerations section to better articulate that.. Thanks, Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Rober= t Raszuk Sent: Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 Authors, Actually when discussing this draft a new concern surfaced which I would=20 like to get your answer on. The draft in section 4.2 says as one of the forwarding rules: o Forwarding to a "stale" route is only used if there are no other paths available to that route. In other words an active path always wins regardless of path selection. "Stale" state is always considered to be less preferred when compared with an active path. In the light of the above rule let's consider a very simple case of dual=20 PE attached site of L3VPN service. Two CEs would inject into their IBGP=20 mesh routes to the remote destination: one marked as STALE and one not=20 marked at all. (Each CE is connected to different PE and each PE RT=20 imports only a single route to a remote hub headquarter to support=20 geographic load balancing). Let me illustrate: VPN Customer HUB PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | | 1| |10 | | R1 ------ R2 1 CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 and=20 R2-CE2 is 10. Prefix X is advertised by remote hub in the given VPN such that PE1 vrf=20 towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has X via PE4= . Let's assume EBGP sessions PE3 to HUB went down, but ethernet link is=20 up, next hop is in the RIB while data plane is gone. Assume no data=20 plane real validation too. /* That is why in my former message I=20 suggested that data plane validation would be necessary */. R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands=20 STALE so selects in his forwarding table path via CE2. R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not=20 understand STALE, never was upgraded to support the forwarding rule=20 stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). R1--R2 produce data plane loop as long as STALE paths are present in the=20 system. Quite fun to troubleshoot too as the issue of PE3 injecting such=20 STALE paths may be on the opposite site of the world. The issue occurs when some routers within the customer site will be able=20 to recognize STALE transitive community and prefer non stale paths in=20 their forwarding planes (or BGP planes for that matter) while others=20 will not as well as when both stale and non stale paths will be present. Question 1: How do you prevent forwarding loop in such case ? Question 2: How do you prevent forwarding loop in the case when customer=20 would have backup connectivity to his sites or connectivity via=20 different VPN provider yet routers in his site only partially understand=20 the STALE community and only partially follow the forwarding rules ? In general as the rule is about mandating some particular order of path=20 forwarding selection what is the mechanism in distributed systems like=20 today's routing to be able to achieve any assurance that such rule is=20 active and enforced across _all_ routers behind EBGP PE-CE L3VPN=20 boundaries in customer sites ? Best regards, R. -------- Original Message -------- Subject: [Idr] draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 +0200 From: Robert Raszuk Reply-To: robert@raszuk.net To: idr@ietf.org List Hi, I have read the draft and have one question and one observation. Question: What is the point of defining DO_NOT_PERSIST community ? In other words why not having PERSIST community set would not mean the same as having path marked with DO_NOT_PERSIST. Observation: I found the below statement in section 4.2: o Forwarding must ensure that the Next Hop to a "stale" route is viable. Of course I agree. But since we stating obvious in the forwarding section I think it would be good to explicitly also state this in the best path selection that next hop to STALE best path must be valid. However sessions especially those between loopbacks do not go down for no reason. Most likely there is network problem which may have caused those sessions to go down. It is therefor likely that LDP session went also down between any of the LSRs in the data path and that in spite of having the paths in BGP and next hops in IGP the LSP required for both quoted L2/L3VPN applications is broken. That may particularly happen when network chooses to use independent control mode for label allocation. I would suggest to at least add the recommendation statement to the document that during best path selection especially for stale paths a validity of required forwarding paradigm to next hop of stale paths should be verified. For example using techniques as described in: draft-ietf-idr-bgp-bestpath-selection-criteria Best regards, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Wed Oct 26 10:24:38 2011 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 DF11821F8ABB for ; Wed, 26 Oct 2011 10:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=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 rQ0npIi05vxw for ; Wed, 26 Oct 2011 10:24:38 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id D286221F8A58 for ; Wed, 26 Oct 2011 10:24:37 -0700 (PDT) Received: (qmail 19992 invoked by uid 399); 26 Oct 2011 17:24:36 -0000 Received: from unknown (HELO ?10.58.3.65?) (65.91.54.2) by mail37.opentransfer.com with SMTP; 26 Oct 2011 17:24:36 -0000 Message-ID: <4EA84254.9000400@raszuk.net> Date: Wed, 26 Oct 2011 19:24:36 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:24:39 -0000 Jim, When one during design phase of a routing protocol or routing protocol extension or modification to it already realizes that enabling such feature may cause real network issue if not done carefully - that should trigger the alarm to rethink the solution and explore alternative approaches to the problem space. We as operators have already hard time to relate enabling a feature within our intradomain boundaries to make sure such rollout is network wide. Here you are asking for the same level of awareness across ebgp boundaries. This is practically unrealistic IMHO. Back to the proposal ... I think that if anything needs to be done is to employ per prefix GR with longer and locally configurable timer. That would address information persistence across direct IBGP sessions. On the RRs use case of this draft we may perhaps agree to disagree, but I do not see large enough probability of correctly engineered RR plane to experience simultaneous multiple ibgp session drops. If that happens the RR placement, platforms or deployment model should be re-engineered. Summary .. I do not think that IDR WG should adopt this document. Just adding a warning to the deployment section is not sufficient. Best regards, R. > Robert, > > The introduction of this technology needs to be carefully evaluated > when being deployed into the network. Your example clearly calls out > how a series of independent design can culminate in incorrect > behavior. Certainly the deployment of persistence on a router that > has interaction with a router that does not needs to be clearly > understood by the network designer. The goal of this draft is to > provide a fairly sophisticated tool that will protect the majority of > customers in the event of a catastrophic failure.. The premise being > the perfect is not the enemy of the good.. I will add text in the > deployment considerations section to better articulate that.. > > Thanks, Jim Uttaro > > -----Original Message----- From: idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: > Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: [Idr] > draft-uttaro-idr-bgp-persistence-00 > > Authors, > > Actually when discussing this draft a new concern surfaced which I > would like to get your answer on. > > The draft in section 4.2 says as one of the forwarding rules: > > o Forwarding to a "stale" route is only used if there are no other > paths available to that route. In other words an active path always > wins regardless of path selection. "Stale" state is always > considered to be less preferred when compared with an active path. > > In the light of the above rule let's consider a very simple case of > dual PE attached site of L3VPN service. Two CEs would inject into > their IBGP mesh routes to the remote destination: one marked as STALE > and one not marked at all. (Each CE is connected to different PE and > each PE RT imports only a single route to a remote hub headquarter to > support geographic load balancing). > > Let me illustrate: > > VPN Customer HUB > > PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | > | 1| |10 | | R1 ------ R2 1 > > CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 > and R2-CE2 is 10. > > Prefix X is advertised by remote hub in the given VPN such that PE1 > vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has > X via PE4. > > Let's assume EBGP sessions PE3 to HUB went down, but ethernet link > is up, next hop is in the RIB while data plane is gone. Assume no > data plane real validation too. /* That is why in my former message > I suggested that data plane validation would be necessary */. > > R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands > STALE so selects in his forwarding table path via CE2. > > R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not > understand STALE, never was upgraded to support the forwarding rule > stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). > > R1--R2 produce data plane loop as long as STALE paths are present in > the system. Quite fun to troubleshoot too as the issue of PE3 > injecting such STALE paths may be on the opposite site of the world. > > The issue occurs when some routers within the customer site will be > able to recognize STALE transitive community and prefer non stale > paths in their forwarding planes (or BGP planes for that matter) > while others will not as well as when both stale and non stale paths > will be present. > > Question 1: How do you prevent forwarding loop in such case ? > > Question 2: How do you prevent forwarding loop in the case when > customer would have backup connectivity to his sites or connectivity > via different VPN provider yet routers in his site only partially > understand the STALE community and only partially follow the > forwarding rules ? > > In general as the rule is about mandating some particular order of > path forwarding selection what is the mechanism in distributed > systems like today's routing to be able to achieve any assurance that > such rule is active and enforced across _all_ routers behind EBGP > PE-CE L3VPN boundaries in customer sites ? > > Best regards, R. > > > -------- Original Message -------- Subject: [Idr] > draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 > +0200 From: Robert Raszuk Reply-To: > robert@raszuk.net To: idr@ietf.org List > > Hi, > > I have read the draft and have one question and one observation. > > Question: > > What is the point of defining DO_NOT_PERSIST community ? In other > words why not having PERSIST community set would not mean the same as > having path marked with DO_NOT_PERSIST. > > Observation: > > I found the below statement in section 4.2: > > o Forwarding must ensure that the Next Hop to a "stale" route is > viable. > > Of course I agree. But since we stating obvious in the forwarding > section I think it would be good to explicitly also state this in > the best path selection that next hop to STALE best path must be > valid. > > However sessions especially those between loopbacks do not go down > for no reason. Most likely there is network problem which may have > caused those sessions to go down. It is therefor likely that LDP > session went also down between any of the LSRs in the data path and > that in spite of having the paths in BGP and next hops in IGP the LSP > required for both quoted L2/L3VPN applications is broken. That may > particularly happen when network chooses to use independent control > mode for label allocation. > > I would suggest to at least add the recommendation statement to the > document that during best path selection especially for stale paths > a validity of required forwarding paradigm to next hop of stale > paths should be verified. > > For example using techniques as described in: > draft-ietf-idr-bgp-bestpath-selection-criteria > > Best regards, R. > > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From enkechen@cisco.com Wed Oct 26 17:42:08 2011 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 2D02521F86C3 for ; Wed, 26 Oct 2011 17:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_13=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 ohFRReEZ20rU for ; Wed, 26 Oct 2011 17:42:07 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1078321F8677 for ; Wed, 26 Oct 2011 17:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=9062; q=dns/txt; s=iport; t=1319676127; x=1320885727; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cCZ/aSVDP8w7V2uekCA74KsytfhVWbyZNE6x8VyRZ3g=; b=Qzqj27Ng4+aOez7q8n1n6CMvmF7RbYUKWMw8uJx62I59CTCq1FJ/QOmy 5nndwpAF2n3Fmvpyj1kPMh1sDe1nuAhYuXMFKlHFMfKyMLGfU375+01z5 zlVAUenLPtVtZKvsH0Omu8Z9DYSWZZtEYbRk1cOtePJDu9/n3rtixH5JK 4=; X-IronPort-AV: E=Sophos;i="4.69,412,1315180800"; d="scan'208";a="10554735" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 27 Oct 2011 00:42:06 +0000 Received: from enkechen-mac.local ([10.155.34.161]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9R0g5RF009084; Thu, 27 Oct 2011 00:42:05 GMT Message-ID: <4EA8A91C.4090305@cisco.com> Date: Wed, 26 Oct 2011 17:43:08 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> In-Reply-To: <4EA84254.9000400@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , robert@raszuk.net Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-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: Thu, 27 Oct 2011 00:42:08 -0000 Hi, folks: I have a hard time in understanding what new problems (beyond the GR) the draft try to solve :-( If the concern is about the simultaneous RR failure as shown in the examples in Sect. 6 Application, that can be addressed easily using GR. As the RRs are not in the forwarding path, it means that the forwarding is not impacted (thus is preserved) during the restart of a RR. The Forwarding State bit (F) in the GR capability should always be set by the RR when it is not in the forwarding path. Also in the case of simultaneous RR failure, I do not see why one would want to retain some routes, but not others, using the communities specified in the draft. As the RRs are not in the forwarding path, wouldn't be better to retain all the routes on a PE/client? As you might be aware, efforts have been underway to address issues with GR found during implementation and deployment. They include the spec respin, notification handling, and implementations. If there are issues in the GR area that are not adequately addressed, I suggest that we try to address them in the GR respin if possible, instead of creating another variation unnecessarily. Thanks. -- Enke On 10/26/11 10:24 AM, Robert Raszuk wrote: > Jim, > > When one during design phase of a routing protocol or routing protocol > extension or modification to it already realizes that enabling such > feature may cause real network issue if not done carefully - that > should trigger the alarm to rethink the solution and explore > alternative approaches to the problem space. > > We as operators have already hard time to relate enabling a feature > within our intradomain boundaries to make sure such rollout is network > wide. Here you are asking for the same level of awareness across ebgp > boundaries. This is practically unrealistic IMHO. > > Back to the proposal ... I think that if anything needs to be done is > to employ per prefix GR with longer and locally configurable timer. > That would address information persistence across direct IBGP sessions. > > On the RRs use case of this draft we may perhaps agree to disagree, > but I do not see large enough probability of correctly engineered RR > plane to experience simultaneous multiple ibgp session drops. If that > happens the RR placement, platforms or deployment model should be > re-engineered. > > Summary .. I do not think that IDR WG should adopt this document. Just > adding a warning to the deployment section is not sufficient. > > Best regards, > R. > > >> Robert, >> >> The introduction of this technology needs to be carefully evaluated >> when being deployed into the network. Your example clearly calls out >> how a series of independent design can culminate in incorrect >> behavior. Certainly the deployment of persistence on a router that >> has interaction with a router that does not needs to be clearly >> understood by the network designer. The goal of this draft is to >> provide a fairly sophisticated tool that will protect the majority of >> customers in the event of a catastrophic failure.. The premise being >> the perfect is not the enemy of the good.. I will add text in the >> deployment considerations section to better articulate that.. >> >> Thanks, Jim Uttaro >> >> -----Original Message----- From: idr-bounces@ietf.org >> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >> Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: [Idr] >> draft-uttaro-idr-bgp-persistence-00 >> >> Authors, >> >> Actually when discussing this draft a new concern surfaced which I >> would like to get your answer on. >> >> The draft in section 4.2 says as one of the forwarding rules: >> >> o Forwarding to a "stale" route is only used if there are no other >> paths available to that route. In other words an active path always >> wins regardless of path selection. "Stale" state is always >> considered to be less preferred when compared with an active path. >> >> In the light of the above rule let's consider a very simple case of >> dual PE attached site of L3VPN service. Two CEs would inject into >> their IBGP mesh routes to the remote destination: one marked as STALE >> and one not marked at all. (Each CE is connected to different PE and >> each PE RT imports only a single route to a remote hub headquarter to >> support geographic load balancing). >> >> Let me illustrate: >> >> VPN Customer HUB >> >> PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | >> | 1| |10 | | R1 ------ R2 1 >> >> CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 >> and R2-CE2 is 10. >> >> Prefix X is advertised by remote hub in the given VPN such that PE1 >> vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has >> X via PE4. >> >> Let's assume EBGP sessions PE3 to HUB went down, but ethernet link >> is up, next hop is in the RIB while data plane is gone. Assume no >> data plane real validation too. /* That is why in my former message >> I suggested that data plane validation would be necessary */. >> >> R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands >> STALE so selects in his forwarding table path via CE2. >> >> R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not >> understand STALE, never was upgraded to support the forwarding rule >> stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). >> >> R1--R2 produce data plane loop as long as STALE paths are present in >> the system. Quite fun to troubleshoot too as the issue of PE3 >> injecting such STALE paths may be on the opposite site of the world. >> >> The issue occurs when some routers within the customer site will be >> able to recognize STALE transitive community and prefer non stale >> paths in their forwarding planes (or BGP planes for that matter) >> while others will not as well as when both stale and non stale paths >> will be present. >> >> Question 1: How do you prevent forwarding loop in such case ? >> >> Question 2: How do you prevent forwarding loop in the case when >> customer would have backup connectivity to his sites or connectivity >> via different VPN provider yet routers in his site only partially >> understand the STALE community and only partially follow the >> forwarding rules ? >> >> In general as the rule is about mandating some particular order of >> path forwarding selection what is the mechanism in distributed >> systems like today's routing to be able to achieve any assurance that >> such rule is active and enforced across _all_ routers behind EBGP >> PE-CE L3VPN boundaries in customer sites ? >> >> Best regards, R. >> >> >> -------- Original Message -------- Subject: [Idr] >> draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 >> +0200 From: Robert Raszuk Reply-To: >> robert@raszuk.net To: idr@ietf.org List >> >> Hi, >> >> I have read the draft and have one question and one observation. >> >> Question: >> >> What is the point of defining DO_NOT_PERSIST community ? In other >> words why not having PERSIST community set would not mean the same as >> having path marked with DO_NOT_PERSIST. >> >> Observation: >> >> I found the below statement in section 4.2: >> >> o Forwarding must ensure that the Next Hop to a "stale" route is >> viable. >> >> Of course I agree. But since we stating obvious in the forwarding >> section I think it would be good to explicitly also state this in >> the best path selection that next hop to STALE best path must be >> valid. >> >> However sessions especially those between loopbacks do not go down >> for no reason. Most likely there is network problem which may have >> caused those sessions to go down. It is therefor likely that LDP >> session went also down between any of the LSRs in the data path and >> that in spite of having the paths in BGP and next hops in IGP the LSP >> required for both quoted L2/L3VPN applications is broken. That may >> particularly happen when network chooses to use independent control >> mode for label allocation. >> >> I would suggest to at least add the recommendation statement to the >> document that during best path selection especially for stale paths >> a validity of required forwarding paradigm to next hop of stale >> paths should be verified. >> >> For example using techniques as described in: >> draft-ietf-idr-bgp-bestpath-selection-criteria >> >> Best regards, R. >> >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From warren@kumari.net Thu Oct 27 06:29:16 2011 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 9ACC221F8634 for ; Thu, 27 Oct 2011 06:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 dd-mz6Ltt5Y7 for ; Thu, 27 Oct 2011 06:29:16 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDC721F85B5 for ; Thu, 27 Oct 2011 06:29:15 -0700 (PDT) Received: from [10.196.205.237] (unknown [199.91.196.1]) by vimes.kumari.net (Postfix) with ESMTPSA id ED2561B40673 for ; Thu, 27 Oct 2011 09:29:13 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Oct 2011 09:29:13 -0400 Message-Id: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> To: idr@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Idr] Accept draft-wkumari-idr-as0-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 Oct 2011 13:29:16 -0000 Hello IDRites, I would like to draw your attention to draft-wkumari-idr-as0-01.txt ( = http://tools.ietf.org/html/draft-wkumari-idr-as0-01 ) - I am asking that = this draft be considered for WG adoption. I have already received some feedback, mainly suggesting: - Add a text for AS number 0 as a reserved in Aggregator and AS4 Aggregator attribute - Add text for AS number 0 as a reserved value in communities and extended communities. (RFC 1997 and Four-octet AS Specific Extended Communities) Also suggested was providing a little more information on what to do it = you do receive a route containing AS0 (more descriptive than just "MUST = NOT accept" (for example, stating that it should be "excluded from the = Phase 2 decision function")). Anyway, I would value your feedback and input. W =20 From robert@raszuk.net Thu Oct 27 08:35:47 2011 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 58D7E21F8BA0 for ; Thu, 27 Oct 2011 08:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 jEnrNePrN3TX for ; Thu, 27 Oct 2011 08:35:46 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 8C70921F8BAE for ; Thu, 27 Oct 2011 08:35:46 -0700 (PDT) Received: (qmail 23736 invoked by uid 399); 27 Oct 2011 15:35:45 -0000 Received: from unknown (HELO ?216.69.69.179?) (216.69.69.179) by mail37.opentransfer.com with SMTP; 27 Oct 2011 15:35:45 -0000 Message-ID: <4EA97A53.7010001@raszuk.net> Date: Thu, 27 Oct 2011 17:35:47 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Warren Kumari References: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> In-Reply-To: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] Accept draft-wkumari-idr-as0-01.txt ? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:35:47 -0000 Hi Warren, I support the draft. However I would also suggest to add AS4_PATH attribute to the draft. Best regards, R. > Hello IDRites, > > I would like to draw your attention to draft-wkumari-idr-as0-01.txt > ( http://tools.ietf.org/html/draft-wkumari-idr-as0-01 ) - I am asking > that this draft be considered for WG adoption. > > > I have already received some feedback, mainly suggesting: > > - Add a text for AS number 0 as a reserved in Aggregator and AS4 > Aggregator attribute > > - Add text for AS number 0 as a reserved value in communities and > extended communities. (RFC 1997 and Four-octet AS Specific Extended > Communities) > > Also suggested was providing a little more information on what to do > it you do receive a route containing AS0 (more descriptive than just > "MUST NOT accept" (for example, stating that it should be "excluded > from the Phase 2 decision function")). > > Anyway, I would value your feedback and input. > > W > > > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From jgs@juniper.net Thu Oct 27 08:47:29 2011 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 2708D21F8B5E for ; Thu, 27 Oct 2011 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6lekrWMlQwO for ; Thu, 27 Oct 2011 08:47:28 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5C92921F8B59 for ; Thu, 27 Oct 2011 08:47:28 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP; Thu, 27 Oct 2011 08:47:28 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 27 Oct 2011 08:46:29 -0700 From: John Scudder To: "idr@ietf.org List" Date: Thu, 27 Oct 2011 08:46:28 -0700 Thread-Topic: [Idr] I-D Action: draft-ietf-idr-optional-transitive-04.txt Thread-Index: AcyUv5dwVcBxhrzMQPCAhtf6jRqOpQ== Message-ID: <29B0F0D2-9065-48D7-BF3C-C25583AB0DB4@juniper.net> References: <20111025181242.29707.90844.idtracker@ietfa.amsl.com> <4EA6FF90.9020202@cisco.com> In-Reply-To: <4EA6FF90.9020202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] I-D Action: draft-ietf-idr-optional-transitive-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: Thu, 27 Oct 2011 15:47:29 -0000 A minor point, the title of the draft is not accurate any more. Since cove= red cases are no longer restricted, "optional-transitive" in the title is m= isleading. We will change the title to be less confusing, probably after t= he -00 blackout is over. --John On Oct 25, 2011, at 2:27 PM, Enke Chen wrote: > Hi, folks: >=20 > The draft has been revised extensively as a result of consolidation with= =20 > draft-chen-ebgp-error-handling-01.txt. >=20 > Here is a summary of the main changes: >=20 > o Use "treat-as-withdraw" / "attribute discard" (instead of session=20 > reset) > whenever possible in order to minimize the impact on routing. >=20 > o Cover the well-known attributes as well as optional attributes >=20 > o Specify that errors with the Attribute Flags should be fixed locally >=20 > o Remove the "Neighbor-Complete flag", and also the check for Partial=20 > flag >=20 > They are no longer needed given our goal of minimizing impact on=20 > routing. >=20 > o Add the following in Operational Considerations: >=20 > When a malformed attribute is indeed detected over an IBGP session, w= e > recommend that routes with the malformed attribute be identified and > traced back to the ingress router in the network where the routes > were sourced or received externally, and then a filter be applied on > the ingress router to prevent the routes from being sourced or=20 > received. >=20 > Thanks. -- Enke >=20 > On 10/25/11 11:12 AM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. This draft is a work item of the Inter-Domain Routing Working Group= of the IETF. >>=20 >> Title : Revised Error Handling for BGP UPDATE Messages >> Author(s) : John G. Scudder >> Enke Chen >> Pradosh Mohapatra >> Keyur Patel >> Filename : draft-ietf-idr-optional-transitive-04.txt >> Pages : 10 >> Date : 2011-10-25 >>=20 >> 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 optional attributes. Finally, it >> revises the error handling procedures for several existing >> attributes. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-idr-optional-transitive-0= 4.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-optional-transitive-04= .txt >> _______________________________________________ >> 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 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Thu Oct 27 13:17:44 2011 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 01E7D21F8B19 for ; Thu, 27 Oct 2011 13:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.549 X-Spam-Level: X-Spam-Status: No, score=-105.549 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 pLQyIeA+QnRo for ; Thu, 27 Oct 2011 13:17:40 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 863F321F8B16 for ; Thu, 27 Oct 2011 13:17:37 -0700 (PDT) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1319746656!44742774!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24324 invoked from network); 27 Oct 2011 20:17:36 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Oct 2011 20:17:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9RKI36M027843; Thu, 27 Oct 2011 16:18:03 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9RKHqGC027675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Oct 2011 16:17:52 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0339.001; Thu, 27 Oct 2011 16:17:24 -0400 From: "UTTARO, JAMES" To: "'Enke Chen'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMZWKuQoAgAQhplCAAIdcwoABIPrw Date: Thu, 27 Oct 2011 20:17:23 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> In-Reply-To: <4EA8A91C.4090305@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.63.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-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: Thu, 27 Oct 2011 20:17:44 -0000 Enke, GR is a solution that is essentially local in scope it does not have the ab= ility to inform downstream speakers of the viability of routing state from = the point of possible control plane failure. OTOH Persistence does propagat= e the condition of state. This provides distinct advantages in terms of cus= tomers awareness of the SPs control plane. One could imagine a customer rec= eiving a STALE path and responding by selecting a backup. Some of the exten= sions to this draft that I have considered in colouring of STALE to inform = if the condition arises from a local ( PE ) or internal iBGP ( RR ) failure= s..=20 GR makes no distinction from STALE state and ACTIVE state.. This can lead t= o the STALE path still being preferred throughout the topology. IMO this is= incorrect behavior regardless of the comparison.=20 PERSISTENCE allows for a customer to indicate which paths should be candida= tes. Customers may want to immediately failover to the backup for some path= s and not for others. GR is not capable of doing this it is all or nothing.= The granularity is not sufficient. It needs to be at the path level. There= may even be a case for having even more granularity i.e a per path timer..= GR is not capable of being extended for either of these cases. GR does not provide protection through successive restarts of the session. = I believe that if this occurs the state will be invalidated. So for a sessi= on that is bouncing due to overload condition GR will not provide the requi= red protection GR does not employ a make before break strategy. All state is invalidated f= irst then the newly learned state is processed. This leads to routing churn= especially if the majority of the state is the same which I am pretty sure= is the case GR invalidates state due to the case of protocol error i.e A malformed upda= te will invalidate all of the state. This is not the desired behavior. GR is not specific as to which events invoke it or not. From my read on the= draft it is not clear if holdtime expiration invokes GR or not.. The draft= is unclear. It is not clear to me how RRs and PEs differ in using GR.=20 The time that state can persist is limit to about 1 hour max.=20 GR does detail the behavior where convergence is not achieved between resta= rts.. Similar to above.. =20 I do not believe that the current GR paradigm can be extended to cover the = majority of the cases above. Thanks, Jim Uttaro -----Original Message----- From: Enke Chen [mailto:enkechen@cisco.com]=20 Sent: Wednesday, October 26, 2011 8:43 PM To: UTTARO, JAMES Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 Hi, folks: I have a hard time in understanding what new problems (beyond the GR)=20 the draft try to solve :-( If the concern is about the simultaneous RR failure as shown in the=20 examples in Sect. 6 Application, that can be addressed easily using GR. =20 As the RRs are not in the forwarding path, it means that the forwarding=20 is not impacted (thus is preserved) during the restart of a RR. The=20 Forwarding State bit (F) in the GR capability should always be set by=20 the RR when it is not in the forwarding path. Also in the case of simultaneous RR failure, I do not see why one would=20 want to retain some routes, but not others, using the communities=20 specified in the draft. As the RRs are not in the forwarding path,=20 wouldn't be better to retain all the routes on a PE/client? As you might be aware, efforts have been underway to address issues with=20 GR found during implementation and deployment. They include the spec=20 respin, notification handling, and implementations. If there are issues=20 in the GR area that are not adequately addressed, I suggest that we try=20 to address them in the GR respin if possible, instead of creating=20 another variation unnecessarily. Thanks. -- Enke On 10/26/11 10:24 AM, Robert Raszuk wrote: > Jim, > > When one during design phase of a routing protocol or routing protocol=20 > extension or modification to it already realizes that enabling such=20 > feature may cause real network issue if not done carefully - that=20 > should trigger the alarm to rethink the solution and explore=20 > alternative approaches to the problem space. > > We as operators have already hard time to relate enabling a feature=20 > within our intradomain boundaries to make sure such rollout is network=20 > wide. Here you are asking for the same level of awareness across ebgp=20 > boundaries. This is practically unrealistic IMHO. > > Back to the proposal ... I think that if anything needs to be done is=20 > to employ per prefix GR with longer and locally configurable timer.=20 > That would address information persistence across direct IBGP sessions. > > On the RRs use case of this draft we may perhaps agree to disagree,=20 > but I do not see large enough probability of correctly engineered RR=20 > plane to experience simultaneous multiple ibgp session drops. If that=20 > happens the RR placement, platforms or deployment model should be=20 > re-engineered. > > Summary .. I do not think that IDR WG should adopt this document. Just=20 > adding a warning to the deployment section is not sufficient. > > Best regards, > R. > > >> Robert, >> >> The introduction of this technology needs to be carefully evaluated >> when being deployed into the network. Your example clearly calls out >> how a series of independent design can culminate in incorrect >> behavior. Certainly the deployment of persistence on a router that >> has interaction with a router that does not needs to be clearly >> understood by the network designer. The goal of this draft is to >> provide a fairly sophisticated tool that will protect the majority of >> customers in the event of a catastrophic failure.. The premise being >> the perfect is not the enemy of the good.. I will add text in the >> deployment considerations section to better articulate that.. >> >> Thanks, Jim Uttaro >> >> -----Original Message----- From: idr-bounces@ietf.org >> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >> Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: [Idr] >> draft-uttaro-idr-bgp-persistence-00 >> >> Authors, >> >> Actually when discussing this draft a new concern surfaced which I >> would like to get your answer on. >> >> The draft in section 4.2 says as one of the forwarding rules: >> >> o Forwarding to a "stale" route is only used if there are no other >> paths available to that route. In other words an active path always >> wins regardless of path selection. "Stale" state is always >> considered to be less preferred when compared with an active path. >> >> In the light of the above rule let's consider a very simple case of >> dual PE attached site of L3VPN service. Two CEs would inject into >> their IBGP mesh routes to the remote destination: one marked as STALE >> and one not marked at all. (Each CE is connected to different PE and >> each PE RT imports only a single route to a remote hub headquarter to >> support geographic load balancing). >> >> Let me illustrate: >> >> VPN Customer HUB >> >> PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | >> | 1| |10 | | R1 ------ R2 1 >> >> CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 >> and R2-CE2 is 10. >> >> Prefix X is advertised by remote hub in the given VPN such that PE1 >> vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has >> X via PE4. >> >> Let's assume EBGP sessions PE3 to HUB went down, but ethernet link >> is up, next hop is in the RIB while data plane is gone. Assume no >> data plane real validation too. /* That is why in my former message >> I suggested that data plane validation would be necessary */. >> >> R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands >> STALE so selects in his forwarding table path via CE2. >> >> R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not >> understand STALE, never was upgraded to support the forwarding rule >> stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). >> >> R1--R2 produce data plane loop as long as STALE paths are present in >> the system. Quite fun to troubleshoot too as the issue of PE3 >> injecting such STALE paths may be on the opposite site of the world. >> >> The issue occurs when some routers within the customer site will be >> able to recognize STALE transitive community and prefer non stale >> paths in their forwarding planes (or BGP planes for that matter) >> while others will not as well as when both stale and non stale paths >> will be present. >> >> Question 1: How do you prevent forwarding loop in such case ? >> >> Question 2: How do you prevent forwarding loop in the case when >> customer would have backup connectivity to his sites or connectivity >> via different VPN provider yet routers in his site only partially >> understand the STALE community and only partially follow the >> forwarding rules ? >> >> In general as the rule is about mandating some particular order of >> path forwarding selection what is the mechanism in distributed >> systems like today's routing to be able to achieve any assurance that >> such rule is active and enforced across _all_ routers behind EBGP >> PE-CE L3VPN boundaries in customer sites ? >> >> Best regards, R. >> >> >> -------- Original Message -------- Subject: [Idr] >> draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 >> +0200 From: Robert Raszuk Reply-To: >> robert@raszuk.net To: idr@ietf.org List >> >> Hi, >> >> I have read the draft and have one question and one observation. >> >> Question: >> >> What is the point of defining DO_NOT_PERSIST community ? In other >> words why not having PERSIST community set would not mean the same as >> having path marked with DO_NOT_PERSIST. >> >> Observation: >> >> I found the below statement in section 4.2: >> >> o Forwarding must ensure that the Next Hop to a "stale" route is >> viable. >> >> Of course I agree. But since we stating obvious in the forwarding >> section I think it would be good to explicitly also state this in >> the best path selection that next hop to STALE best path must be >> valid. >> >> However sessions especially those between loopbacks do not go down >> for no reason. Most likely there is network problem which may have >> caused those sessions to go down. It is therefor likely that LDP >> session went also down between any of the LSRs in the data path and >> that in spite of having the paths in BGP and next hops in IGP the LSP >> required for both quoted L2/L3VPN applications is broken. That may >> particularly happen when network chooses to use independent control >> mode for label allocation. >> >> I would suggest to at least add the recommendation statement to the >> document that during best path selection especially for stale paths >> a validity of required forwarding paradigm to next hop of stale >> paths should be verified. >> >> For example using techniques as described in: >> draft-ietf-idr-bgp-bestpath-selection-criteria >> >> Best regards, R. >> >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> >> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >> >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Thu Oct 27 13:31:40 2011 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 D25B921F8B4B for ; Thu, 27 Oct 2011 13:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.639 X-Spam-Level: X-Spam-Status: No, score=-105.639 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 1VcgBfZWkWSF for ; Thu, 27 Oct 2011 13:31:39 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCC921F8B42 for ; Thu, 27 Oct 2011 13:31:34 -0700 (PDT) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1319747492!46109529!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12051 invoked from network); 27 Oct 2011 20:31:33 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Oct 2011 20:31:33 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9RKVxYk016305; Thu, 27 Oct 2011 16:32:00 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p9RKVqFT016158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Oct 2011 16:31:52 -0400 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0339.001; Thu, 27 Oct 2011 16:31:24 -0400 From: "UTTARO, JAMES" To: "'robert@raszuk.net'" Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence-00 Thread-Index: AQHMkEAnLP0iAkRlVkChUYWtkZqOMZWKuQoAgAQhplCAAFAiAIABf8Jw Date: Thu, 27 Oct 2011 20:31:24 +0000 Message-ID: References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> In-Reply-To: <4EA84254.9000400@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.63.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-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: Thu, 27 Oct 2011 20:31:40 -0000 Robert, To be honest I do not agree and am confused by your comments.. There are m= any specifications that demand correct deployment in a network to prevent u= nwanted behavior. Some immediate examples come to mind: L3VPN. If the operator mis-configures RTs or stitches incorrectly VPN pollu= tion can easily occur. There is no protection that I know of in the draft t= o prevent this. RT Constrain. If incorrectly deployed in a network with devices that do and= don't support the VPN distribution graph will be incorrectly built. This w= ill result in customers VPN being compromised. The draft does not prevent t= his. It is the responsibility of the network designers to determine how to deplo= y powerful technology into their networks. Part of this is to ensure that w= e do not create a "real network issue if not done carefully ". We do not ha= ve the luxury of not being careful. Generally speaking when introducing tec= hnology with new capability the expectation is that the network architects/= designers understand the technology and deploy it correctly.=20 Thanks, Jim Uttaro -----Original Message----- From: Robert Raszuk [mailto:robert@raszuk.net]=20 Sent: Wednesday, October 26, 2011 1:25 PM To: UTTARO, JAMES Cc: idr@ietf.org List Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 Jim, When one during design phase of a routing protocol or routing protocol=20 extension or modification to it already realizes that enabling such=20 feature may cause real network issue if not done carefully - that should=20 trigger the alarm to rethink the solution and explore alternative=20 approaches to the problem space. We as operators have already hard time to relate enabling a feature=20 within our intradomain boundaries to make sure such rollout is network=20 wide. Here you are asking for the same level of awareness across ebgp=20 boundaries. This is practically unrealistic IMHO. Back to the proposal ... I think that if anything needs to be done is to=20 employ per prefix GR with longer and locally configurable timer. That=20 would address information persistence across direct IBGP sessions. On the RRs use case of this draft we may perhaps agree to disagree, but=20 I do not see large enough probability of correctly engineered RR plane=20 to experience simultaneous multiple ibgp session drops. If that happens=20 the RR placement, platforms or deployment model should be re-engineered. Summary .. I do not think that IDR WG should adopt this document. Just=20 adding a warning to the deployment section is not sufficient. Best regards, R. > Robert, > > The introduction of this technology needs to be carefully evaluated > when being deployed into the network. Your example clearly calls out > how a series of independent design can culminate in incorrect > behavior. Certainly the deployment of persistence on a router that > has interaction with a router that does not needs to be clearly > understood by the network designer. The goal of this draft is to > provide a fairly sophisticated tool that will protect the majority of > customers in the event of a catastrophic failure.. The premise being > the perfect is not the enemy of the good.. I will add text in the > deployment considerations section to better articulate that.. > > Thanks, Jim Uttaro > > -----Original Message----- From: idr-bounces@ietf.org > [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: > Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: [Idr] > draft-uttaro-idr-bgp-persistence-00 > > Authors, > > Actually when discussing this draft a new concern surfaced which I > would like to get your answer on. > > The draft in section 4.2 says as one of the forwarding rules: > > o Forwarding to a "stale" route is only used if there are no other > paths available to that route. In other words an active path always > wins regardless of path selection. "Stale" state is always > considered to be less preferred when compared with an active path. > > In the light of the above rule let's consider a very simple case of > dual PE attached site of L3VPN service. Two CEs would inject into > their IBGP mesh routes to the remote destination: one marked as STALE > and one not marked at all. (Each CE is connected to different PE and > each PE RT imports only a single route to a remote hub headquarter to > support geographic load balancing). > > Let me illustrate: > > VPN Customer HUB > > PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | > | 1| |10 | | R1 ------ R2 1 > > CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 > and R2-CE2 is 10. > > Prefix X is advertised by remote hub in the given VPN such that PE1 > vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has > X via PE4. > > Let's assume EBGP sessions PE3 to HUB went down, but ethernet link > is up, next hop is in the RIB while data plane is gone. Assume no > data plane real validation too. /* That is why in my former message > I suggested that data plane validation would be necessary */. > > R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands > STALE so selects in his forwarding table path via CE2. > > R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not > understand STALE, never was upgraded to support the forwarding rule > stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). > > R1--R2 produce data plane loop as long as STALE paths are present in > the system. Quite fun to troubleshoot too as the issue of PE3 > injecting such STALE paths may be on the opposite site of the world. > > The issue occurs when some routers within the customer site will be > able to recognize STALE transitive community and prefer non stale > paths in their forwarding planes (or BGP planes for that matter) > while others will not as well as when both stale and non stale paths > will be present. > > Question 1: How do you prevent forwarding loop in such case ? > > Question 2: How do you prevent forwarding loop in the case when > customer would have backup connectivity to his sites or connectivity > via different VPN provider yet routers in his site only partially > understand the STALE community and only partially follow the > forwarding rules ? > > In general as the rule is about mandating some particular order of > path forwarding selection what is the mechanism in distributed > systems like today's routing to be able to achieve any assurance that > such rule is active and enforced across _all_ routers behind EBGP > PE-CE L3VPN boundaries in customer sites ? > > Best regards, R. > > > -------- Original Message -------- Subject: [Idr] > draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 > +0200 From: Robert Raszuk Reply-To: > robert@raszuk.net To: idr@ietf.org List > > Hi, > > I have read the draft and have one question and one observation. > > Question: > > What is the point of defining DO_NOT_PERSIST community ? In other > words why not having PERSIST community set would not mean the same as > having path marked with DO_NOT_PERSIST. > > Observation: > > I found the below statement in section 4.2: > > o Forwarding must ensure that the Next Hop to a "stale" route is > viable. > > Of course I agree. But since we stating obvious in the forwarding > section I think it would be good to explicitly also state this in > the best path selection that next hop to STALE best path must be > valid. > > However sessions especially those between loopbacks do not go down > for no reason. Most likely there is network problem which may have > caused those sessions to go down. It is therefor likely that LDP > session went also down between any of the LSRs in the data path and > that in spite of having the paths in BGP and next hops in IGP the LSP > required for both quoted L2/L3VPN applications is broken. That may > particularly happen when network chooses to use independent control > mode for label allocation. > > I would suggest to at least add the recommendation statement to the > document that during best path selection especially for stale paths > a validity of required forwarding paradigm to next hop of stale > paths should be verified. > > For example using techniques as described in: > draft-ietf-idr-bgp-bestpath-selection-criteria > > Best regards, R. > > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ Idr mailing list > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > From robert@raszuk.net Thu Oct 27 14:49:30 2011 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 42E1B21F84AF for ; Thu, 27 Oct 2011 14:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 bc1T+XOseZpc for ; Thu, 27 Oct 2011 14:49:29 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 747B621F84AE for ; Thu, 27 Oct 2011 14:49:29 -0700 (PDT) Received: (qmail 28608 invoked by uid 399); 27 Oct 2011 21:49:28 -0000 Received: from unknown (HELO ?216.69.69.179?) (216.69.69.179) by mail37.opentransfer.com with SMTP; 27 Oct 2011 21:49:28 -0000 Message-ID: <4EA9D1EA.3020109@raszuk.net> Date: Thu, 27 Oct 2011 23:49:30 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 21:49:30 -0000 Hello Jim, L3VPN RT assignment is how you define a VPN policy. Of course if you misconfigure policy the system will take it and execute accordingly. That is in fact a L3VPN drawback not something to be proud of. Customers subscribing to L3VPN service must trust provider how their routes are distributed by SP and to whom else are exported. I do know for a fact that some customers just do not trust SP to handle their route distribution. Those customers either ask for L2VPN service or purchase their transit links directly. RT Constrain - I do not see how this can cause wrong construction of VPN distribution graph when deployed partially. Basically PEs which do not support RT-Constrain will get full set of VPNv4 routes and RRs which such PEs are connected to will need to keep all of them. I do not see any issue if you just enable RT constrain on one PE and push RT routes from such PE to RR(s). Please illustrate a scenario where partially deployed RT Constrain results in "VPN distribution graph will be incorrectly built". Maybe we have missed something ... > It is the responsibility of the network designers to determine how to > deploy powerful technology into their networks. I could perhaps agree with that statement in general. However when you are injecting STALE routes to your EBGP peers you have zero control over their network. Best regards, R. > Robert, > > To be honest I do not agree and am confused by your comments.. There > are many specifications that demand correct deployment in a network > to prevent unwanted behavior. Some immediate examples come to mind: > > L3VPN. If the operator mis-configures RTs or stitches incorrectly VPN > pollution can easily occur. There is no protection that I know of in > the draft to prevent this. > > RT Constrain. If incorrectly deployed in a network with devices that > do and don't support the VPN distribution graph will be incorrectly > built. This will result in customers VPN being compromised. The draft > does not prevent this. > > It is the responsibility of the network designers to determine how to > deploy powerful technology into their networks. Part of this is to > ensure that we do not create a "real network issue if not done > carefully ". We do not have the luxury of not being careful. > Generally speaking when introducing technology with new capability > the expectation is that the network architects/designers understand > the technology and deploy it correctly. > > Thanks, Jim Uttaro > > -----Original Message----- From: Robert Raszuk > [mailto:robert@raszuk.net] Sent: Wednesday, October 26, 2011 1:25 PM > To: UTTARO, JAMES Cc: idr@ietf.org List Subject: Re: [Idr] > draft-uttaro-idr-bgp-persistence-00 > > Jim, > > When one during design phase of a routing protocol or routing > protocol extension or modification to it already realizes that > enabling such feature may cause real network issue if not done > carefully - that should trigger the alarm to rethink the solution and > explore alternative approaches to the problem space. > > We as operators have already hard time to relate enabling a feature > within our intradomain boundaries to make sure such rollout is > network wide. Here you are asking for the same level of awareness > across ebgp boundaries. This is practically unrealistic IMHO. > > Back to the proposal ... I think that if anything needs to be done is > to employ per prefix GR with longer and locally configurable timer. > That would address information persistence across direct IBGP > sessions. > > On the RRs use case of this draft we may perhaps agree to disagree, > but I do not see large enough probability of correctly engineered RR > plane to experience simultaneous multiple ibgp session drops. If that > happens the RR placement, platforms or deployment model should be > re-engineered. > > Summary .. I do not think that IDR WG should adopt this document. > Just adding a warning to the deployment section is not sufficient. > > Best regards, R. From enkechen@cisco.com Thu Oct 27 23:18:22 2011 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 A76B121F8B0E for ; Thu, 27 Oct 2011 23:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 JAnwzRtt3OOP for ; Thu, 27 Oct 2011 23:18:20 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE8021F8B0C for ; Thu, 27 Oct 2011 23:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=34749; q=dns/txt; s=iport; t=1319782700; x=1320992300; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=0afKxcp99vYpy9vbpr+hrcMYcntAvl23XGlsUdDIOig=; b=L51pe+dDwcZx9xEvjee9CH2NdtLeNpEbLwoKxAP4ewH3oaKwJ1Zz0qTV AzlE3+RPlI10niCEo+Dz96/Rr2a2IrhyZEcG//86HgIe1EuY9MY23kBtW Ogc2Q/iR4+COg5IGHdegYzZ6iswbDvYbJ2H72H93vekQc3RSfHAP0cq0C g=; X-IronPort-AV: E=Sophos;i="4.69,417,1315180800"; d="scan'208,217";a="10867177" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 28 Oct 2011 06:18:20 +0000 Received: from sjc-vpn6-139.cisco.com (sjc-vpn6-139.cisco.com [10.21.120.139]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9S6IJAr032593; Fri, 28 Oct 2011 06:18:19 GMT Message-ID: <4EAA496C.9070605@cisco.com> Date: Thu, 27 Oct 2011 23:19:24 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "UTTARO, JAMES" References: <4EA1F0FB.3090100@raszuk.net> <4EA487E4.2040201@raszuk.net> <4EA84254.9000400@raszuk.net> <4EA8A91C.4090305@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030002050604080607060202" Cc: "idr@ietf.org List" , "robert@raszuk.net" Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-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, 28 Oct 2011 06:18:22 -0000 This is a multi-part message in MIME format. --------------030002050604080607060202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jim, My comments are inlined. On 10/27/11 1:17 PM, UTTARO, JAMES wrote: > Enke, > > GR is a solution that is essentially local in scope it does not have the ability to inform downstream speakers of the viability of routing state from the point of possible control plane failure. OTOH Persistence does propagate the condition of state. This provides distinct advantages in terms of customers awareness of the SPs control plane. One could imagine a customer receiving a STALE path and responding by selecting a backup. Some of the extensions to this draft that I have considered in colouring of STALE to inform if the condition arises from a local ( PE ) or internal iBGP ( RR ) failures.. > > GR makes no distinction from STALE state and ACTIVE state.. This can lead to the STALE path still being preferred throughout the topology. IMO this is incorrect behavior regardless of the comparison. > > PERSISTENCE allows for a customer to indicate which paths should be candidates. Customers may want to immediately failover to the backup for some paths and not for others. GR is not capable of doing this it is all or nothing. The granularity is not sufficient. It needs to be at the path level. There may even be a case for having even more granularity i.e a per path timer.. GR is not capable of being extended for either of these cases. I am not sure how this path level persistence would work operationally. Without the detailed information of a provider's network, how would a customer know what kind of failures and recovery that they might experience? Consider the example of the simultaneous RR failures in the draft, why wouldn't any customer not to want to protect against such failures? The end result could be that the PERSISTENCE flag is always set, thus losing its significance. Regarding the use of the STALE state vs ACTIVE state, clearly there is a tradeoff. GR uses the stale routes in order to avoid forwarding churns, which has been a critical requirement for a long time. If there is a real need for favoring a ACTIVE one over a STALE one in GR, it can be done by a simple knob. As you know, BGP is full of knobs that adjust behaviors for different needs :-) > > GR does not provide protection through successive restarts of the session. I believe that if this occurs the state will be invalidated. So for a session that is bouncing due to overload condition GR will not provide the required protection This can be addressed by a simple knob to set the min stale timer for GR. > > GR does not employ a make before break strategy. All state is invalidated first then the newly learned state is processed. This leads to routing churn especially if the majority of the state is the same which I am pretty sure is the case Such behavior would be an implementation bug that needs to be fixed. But it is not an issue with the protocol itself. This is what we have in 4.2. Procedures for the Receiving Speaker, RFC 4724: --- The Receiving Speaker MUST replace the stale routes by the routing updates received from the peer. Once the End-of-RIB marker for an address family is received from the peer, it MUST immediately remove any routes from the peer that are still marked as stale for that address family. --- There are several possibilities for the premature purge of the stale routes. For example, the "Forwarding state" flag was somehow not set after the session was re-established, or the the EOR was sent prematurely. Further investigation will be needed in order to identify any possible implementation or config issues involved in your setup. > > GR invalidates state due to the case of protocol error i.e A malformed update will invalidate all of the state. This is not the desired behavior. It has been addressed by the following extension: http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-notification/ > > GR is not specific as to which events invoke it or not. From my read on the draft it is not clear if holdtime expiration invokes GR or not.. The draft is unclear. I think that it is covered by the above extension. If not, it should be clarified. > It is not clear to me how RRs and PEs differ in using GR. I think that there is a main difference when a RR is not in the forwarding path. In that case, the RR should always set the F bit in the GR Capability so that its clients will continue forwarding after they lose the sessions with RR. It is a deployment issue, though. > > The time that state can persist is limit to about 1 hour max. I think that you are talking about the "Restart time" field which has 12 bits and amount to about 68 minutes. The "Restart time" is for the session re-establishment. It does not impact the duration for holding stale routes after the session is re-established. If the session does not get re-established in 68 minutes, the stale routes would be purged. That is a long time, isn't it? However, if one really wants to extend the session re-establishment time and continue to hold stale routes, it can be done by a simple knob. > > GR does detail the behavior where convergence is not achieved between restarts.. Similar to above.. The min stale timer knob can cover it (see above). But do you meant "does not"? We can certainly clarify in 4724bis if that is the case. > > > I do not believe that the current GR paradigm can be extended to cover the majority of the cases above. Except for the path level persistence you mentioned, I believe the GR will be able to address all other persistence requirements you listed, with some simple knobs and some implementation enhancements. > > Thanks, > Jim Uttaro Thanks. -- Enke > > -----Original Message----- > From: Enke Chen [mailto:enkechen@cisco.com] > Sent: Wednesday, October 26, 2011 8:43 PM > To: UTTARO, JAMES > Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen > Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00 > > Hi, folks: > > I have a hard time in understanding what new problems (beyond the GR) > the draft try to solve :-( > > If the concern is about the simultaneous RR failure as shown in the > examples in Sect. 6 Application, that can be addressed easily using GR. > As the RRs are not in the forwarding path, it means that the forwarding > is not impacted (thus is preserved) during the restart of a RR. The > Forwarding State bit (F) in the GR capability should always be set by > the RR when it is not in the forwarding path. > > Also in the case of simultaneous RR failure, I do not see why one would > want to retain some routes, but not others, using the communities > specified in the draft. As the RRs are not in the forwarding path, > wouldn't be better to retain all the routes on a PE/client? > > As you might be aware, efforts have been underway to address issues with > GR found during implementation and deployment. They include the spec > respin, notification handling, and implementations. If there are issues > in the GR area that are not adequately addressed, I suggest that we try > to address them in the GR respin if possible, instead of creating > another variation unnecessarily. > > Thanks. -- Enke > > > On 10/26/11 10:24 AM, Robert Raszuk wrote: >> Jim, >> >> When one during design phase of a routing protocol or routing protocol >> extension or modification to it already realizes that enabling such >> feature may cause real network issue if not done carefully - that >> should trigger the alarm to rethink the solution and explore >> alternative approaches to the problem space. >> >> We as operators have already hard time to relate enabling a feature >> within our intradomain boundaries to make sure such rollout is network >> wide. Here you are asking for the same level of awareness across ebgp >> boundaries. This is practically unrealistic IMHO. >> >> Back to the proposal ... I think that if anything needs to be done is >> to employ per prefix GR with longer and locally configurable timer. >> That would address information persistence across direct IBGP sessions. >> >> On the RRs use case of this draft we may perhaps agree to disagree, >> but I do not see large enough probability of correctly engineered RR >> plane to experience simultaneous multiple ibgp session drops. If that >> happens the RR placement, platforms or deployment model should be >> re-engineered. >> >> Summary .. I do not think that IDR WG should adopt this document. Just >> adding a warning to the deployment section is not sufficient. >> >> Best regards, >> R. >> >> >>> Robert, >>> >>> The introduction of this technology needs to be carefully evaluated >>> when being deployed into the network. Your example clearly calls out >>> how a series of independent design can culminate in incorrect >>> behavior. Certainly the deployment of persistence on a router that >>> has interaction with a router that does not needs to be clearly >>> understood by the network designer. The goal of this draft is to >>> provide a fairly sophisticated tool that will protect the majority of >>> customers in the event of a catastrophic failure.. The premise being >>> the perfect is not the enemy of the good.. I will add text in the >>> deployment considerations section to better articulate that.. >>> >>> Thanks, Jim Uttaro >>> >>> -----Original Message----- From: idr-bounces@ietf.org >>> [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: >>> Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: [Idr] >>> draft-uttaro-idr-bgp-persistence-00 >>> >>> Authors, >>> >>> Actually when discussing this draft a new concern surfaced which I >>> would like to get your answer on. >>> >>> The draft in section 4.2 says as one of the forwarding rules: >>> >>> o Forwarding to a "stale" route is only used if there are no other >>> paths available to that route. In other words an active path always >>> wins regardless of path selection. "Stale" state is always >>> considered to be less preferred when compared with an active path. >>> >>> In the light of the above rule let's consider a very simple case of >>> dual PE attached site of L3VPN service. Two CEs would inject into >>> their IBGP mesh routes to the remote destination: one marked as STALE >>> and one not marked at all. (Each CE is connected to different PE and >>> each PE RT imports only a single route to a remote hub headquarter to >>> support geographic load balancing). >>> >>> Let me illustrate: >>> >>> VPN Customer HUB >>> >>> PE3 PE4 SP PE1 PE2 | | | | CE1 CE2 | >>> | 1| |10 | | R1 ------ R2 1 >>> >>> CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1 >>> and R2-CE2 is 10. >>> >>> Prefix X is advertised by remote hub in the given VPN such that PE1 >>> vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has >>> X via PE4. >>> >>> Let's assume EBGP sessions PE3 to HUB went down, but ethernet link >>> is up, next hop is in the RIB while data plane is gone. Assume no >>> data plane real validation too. /* That is why in my former message >>> I suggested that data plane validation would be necessary */. >>> >>> R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands >>> STALE so selects in his forwarding table path via CE2. >>> >>> R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not >>> understand STALE, never was upgraded to support the forwarding rule >>> stated above in the draft and chooses X via CE1 (NH metric 2 vs 10). >>> >>> R1--R2 produce data plane loop as long as STALE paths are present in >>> the system. Quite fun to troubleshoot too as the issue of PE3 >>> injecting such STALE paths may be on the opposite site of the world. >>> >>> The issue occurs when some routers within the customer site will be >>> able to recognize STALE transitive community and prefer non stale >>> paths in their forwarding planes (or BGP planes for that matter) >>> while others will not as well as when both stale and non stale paths >>> will be present. >>> >>> Question 1: How do you prevent forwarding loop in such case ? >>> >>> Question 2: How do you prevent forwarding loop in the case when >>> customer would have backup connectivity to his sites or connectivity >>> via different VPN provider yet routers in his site only partially >>> understand the STALE community and only partially follow the >>> forwarding rules ? >>> >>> In general as the rule is about mandating some particular order of >>> path forwarding selection what is the mechanism in distributed >>> systems like today's routing to be able to achieve any assurance that >>> such rule is active and enforced across _all_ routers behind EBGP >>> PE-CE L3VPN boundaries in customer sites ? >>> >>> Best regards, R. >>> >>> >>> -------- Original Message -------- Subject: [Idr] >>> draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55 >>> +0200 From: Robert Raszuk Reply-To: >>> robert@raszuk.net To: idr@ietf.org List >>> >>> Hi, >>> >>> I have read the draft and have one question and one observation. >>> >>> Question: >>> >>> What is the point of defining DO_NOT_PERSIST community ? In other >>> words why not having PERSIST community set would not mean the same as >>> having path marked with DO_NOT_PERSIST. >>> >>> Observation: >>> >>> I found the below statement in section 4.2: >>> >>> o Forwarding must ensure that the Next Hop to a "stale" route is >>> viable. >>> >>> Of course I agree. But since we stating obvious in the forwarding >>> section I think it would be good to explicitly also state this in >>> the best path selection that next hop to STALE best path must be >>> valid. >>> >>> However sessions especially those between loopbacks do not go down >>> for no reason. Most likely there is network problem which may have >>> caused those sessions to go down. It is therefor likely that LDP >>> session went also down between any of the LSRs in the data path and >>> that in spite of having the paths in BGP and next hops in IGP the LSP >>> required for both quoted L2/L3VPN applications is broken. That may >>> particularly happen when network chooses to use independent control >>> mode for label allocation. >>> >>> I would suggest to at least add the recommendation statement to the >>> document that during best path selection especially for stale paths >>> a validity of required forwarding paradigm to next hop of stale >>> paths should be verified. >>> >>> For example using techniques as described in: >>> draft-ietf-idr-bgp-bestpath-selection-criteria >>> >>> Best regards, R. >>> >>> >>> _______________________________________________ Idr mailing list >>> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >>> >>> >>> _______________________________________________ Idr mailing list >>> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >>> >>> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr --------------030002050604080607060202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jim,

My comments are inlined.

On 10/27/11 1:17 PM, UTTARO, JAMES wrote: 
Enke,

GR is a solution that is essentially local in scope it does not have the ability to inform downstream speakers of the viability of routing state from the point of possible control plane failure. OTOH Persistence does propagate the condition of state. This provides distinct advantages in terms of customers awareness of the SPs control plane. One could imagine a customer receiving a STALE path and responding by selecting a backup. Some of the extensions to this draft that I have considered in colouring of STALE to inform if the condition arises from a local ( PE ) or internal iBGP ( RR ) failures.. 

GR makes no distinction from STALE state and ACTIVE state.. This can lead to the STALE path still being preferred throughout the topology. IMO this is incorrect behavior regardless of the comparison. 

PERSISTENCE allows for a customer to indicate which paths should be candidates. Customers may want to immediately failover to the backup for some paths and not for others. GR is not capable of doing this it is all or nothing. The granularity is not sufficient. It needs to be at the path level. There may even be a case for having even more granularity i.e a per path timer.. GR is not capable of being extended for either of these cases.

I am not sure how this path level persistence would work operationally.   Without the detailed information of a provider's network, how would a customer know what kind of failures and recovery that they might experience?   Consider the example of the simultaneous RR failures in the draft,  why wouldn't any customer not to want to protect against such failures?   The end result could be that the PERSISTENCE flag is always set, thus losing its significance.

Regarding the use of the STALE state vs ACTIVE state, clearly there is a tradeoff.   GR uses the stale routes in order to avoid forwarding churns, which has been a critical requirement for a long time.   If there is a real need for favoring a ACTIVE one over a STALE one in GR, it can be done by a simple knob.

As you know, BGP is full of knobs that adjust behaviors for different needs :-)


GR does not provide protection through successive restarts of the session. I believe that if this occurs the state will be invalidated. So for a session that is bouncing due to overload condition GR will not provide the required protection

This can be addressed by a simple knob to set the min stale timer for GR.


GR does not employ a make before break strategy. All state is invalidated first then the newly learned state is processed. This leads to routing churn especially if the majority of the state is the same which I am pretty sure is the case

Such behavior would be an implementation bug that needs to be fixed.  But it is not an issue with the protocol itself.

This is what we have in 4.2. Procedures for the Receiving Speaker, RFC 4724:

---
 
   The Receiving Speaker MUST replace the stale routes by the routing
   updates received from the peer.  Once the End-of-RIB marker for an
   address family is received from the peer, it MUST immediately remove
   any routes from the peer that are still marked as stale for that
   address family.
---

There are several possibilities for the premature purge of the stale routes. For example, the "Forwarding state" flag was somehow not set after the session was re-established, or the the EOR was sent prematurely.   Further investigation will be needed in order to identify any possible implementation or config issues involved in your setup.


GR invalidates state due to the case of protocol error i.e A malformed update will invalidate all of the state. This is not the desired behavior.

It has been addressed by the following extension:

http://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-gr-notification/


GR is not specific as to which events invoke it or not. From my read on the draft it is not clear if holdtime expiration invokes GR or not.. The draft is unclear.

I think that it is covered by the above extension.  If not, it should be clarified.

It is not clear to me how RRs and PEs differ in using GR.

I think that there is a main difference when a RR is not in the forwarding path.  In that case, the RR should always set the F bit in the GR Capability so that its clients will continue forwarding after they lose the sessions with RR.  It is a deployment issue, though.


The time that state can persist is limit to about 1 hour max.

I think that you are talking about the "Restart time" field which has 12 bits and amount to about 68 minutes.  The "Restart time" is for the session re-establishment.  It does not impact the duration for holding stale routes after the session is re-established.

If the session does not get re-established in 68 minutes, the stale routes would be purged.  That is a long time, isn't it?   However, if one really wants to extend the session re-establishment time and continue to hold stale routes, it can be done by a simple knob.


GR does detail the behavior where convergence is not achieved between restarts.. Similar to above..

The min stale timer knob can cover it (see above).

But do you meant "does not"?  We can certainly clarify in 4724bis if that is the case.

 

I do not believe that the current GR paradigm can be extended to cover the majority of the cases above.

Except for the path level persistence you mentioned, I believe the GR will be able to address all other persistence requirements you listed, with some simple knobs and some implementation enhancements. 


Thanks,
	Jim Uttaro

Thanks.   -- Enke


-----Original Message-----
From: Enke Chen [mailto:enkechen@cisco.com] 
Sent: Wednesday, October 26, 2011 8:43 PM
To: UTTARO, JAMES
Cc: robert@raszuk.net; idr@ietf.org List; Enke Chen
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence-00

Hi, folks:

I have a hard time in understanding what new problems (beyond the GR) 
the draft try to solve :-(

If the concern is about the simultaneous RR failure as shown in the 
examples in Sect. 6 Application, that can be addressed easily using GR.  
As the RRs are not in the forwarding path, it means that the forwarding 
is not impacted (thus is preserved) during the restart of a RR.   The 
Forwarding State bit (F) in the GR capability should always be set by 
the RR when it is not in the forwarding path.

Also in the case of simultaneous RR failure, I do not see why one would 
want to retain some routes, but not others, using the communities 
specified in the draft.  As the RRs are not in the forwarding path, 
wouldn't be better to retain all the routes on a PE/client?

As you might be aware, efforts have been underway to address issues with 
GR found during implementation and deployment. They include the spec 
respin, notification handling, and implementations.  If there are issues 
in the GR area that are not adequately addressed,  I suggest that we try 
to address them in the GR respin if possible, instead of creating 
another variation unnecessarily.

Thanks.   -- Enke


On 10/26/11 10:24 AM, Robert Raszuk wrote:

Jim,

When one during design phase of a routing protocol or routing protocol 
extension or modification to it already realizes that enabling such 
feature may cause real network issue if not done carefully - that 
should trigger the alarm to rethink the solution and explore 
alternative approaches to the problem space.

We as operators have already hard time to relate enabling a feature 
within our intradomain boundaries to make sure such rollout is network 
wide. Here you are asking for the same level of awareness across ebgp 
boundaries. This is practically unrealistic IMHO.

Back to the proposal ... I think that if anything needs to be done is 
to employ per prefix GR with longer and locally configurable timer. 
That would address information persistence across direct IBGP sessions.

On the RRs use case of this draft we may perhaps agree to disagree, 
but I do not see large enough probability of correctly engineered RR 
plane to experience simultaneous multiple ibgp session drops. If that 
happens the RR placement, platforms or deployment model should be 
re-engineered.

Summary .. I do not think that IDR WG should adopt this document. Just 
adding a warning to the deployment section is not sufficient.

Best regards,
R.



Robert,

The introduction of this technology needs to be carefully evaluated
when being deployed into the network. Your example clearly calls out
how a series of independent design can culminate in incorrect
behavior. Certainly the deployment of persistence on a router that
has interaction with a router that does not needs to be clearly
understood by the network designer. The goal of this draft is to
provide a fairly sophisticated tool that will protect the majority of
customers in the event of a catastrophic failure.. The premise being
the perfect is not the enemy of the good.. I will add text in the
deployment considerations section to better articulate that..

Thanks, Jim Uttaro

-----Original Message----- From: idr-bounces@ietf.org
[mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent:
Sunday, October 23, 2011 5:32 PM To: idr@ietf.org List Subject: [Idr]
draft-uttaro-idr-bgp-persistence-00

Authors,

Actually when discussing this draft a new concern surfaced which I
would like to get your answer on.

The draft in section 4.2 says as one of the forwarding rules:

o  Forwarding to a "stale" route is only used if there are no other
paths available to that route.  In other words an active path always
wins regardless of path selection.  "Stale" state is always
considered to be less preferred when compared with an active path.

In the light of the above rule let's consider a very simple case of
dual PE attached site of L3VPN service. Two CEs would inject into
their IBGP mesh routes to the remote destination: one marked as STALE
and  one not marked at all. (Each CE is connected to different PE and
each PE RT imports only a single route to a remote hub headquarter to
support geographic load balancing).

Let me illustrate:

VPN Customer HUB

PE3      PE4 SP PE1      PE2 |        | |        | CE1      CE2 |
| 1|        |10 |        | R1 ------ R2 1

CE1,CE2,R1,R2 are in IBGP mesh. IGP metric of CE1-R1 and R1-R2 are 1
and R2-CE2 is 10.

Prefix X is advertised by remote hub in the given VPN such that PE1
vrf towards CE1 only has X via PE3 and PE2's vrf towards CE2 only has
X via PE4.

Let's assume EBGP sessions PE3 to HUB went down, but ethernet link
is up, next hop is in the RIB while data plane is gone. Assume no
data plane real validation too. /* That is why in my former message
I suggested that data plane validation would be necessary */.

R1 has X via PE1/S (stale) and X via PE2/A (active) - it understands
STALE so selects in his forwarding table path via CE2.

R2 has X via PE1/S (stale) and X via PE2/A (active) - it does not
understand STALE, never was upgraded to support the forwarding rule
stated above in the draft and chooses X via CE1 (NH metric 2 vs 10).

R1--R2 produce data plane loop as long as STALE paths are present in
the system. Quite fun to troubleshoot too as the issue of PE3
injecting such STALE paths may be on the opposite site of the world.

The issue occurs when some routers within the customer site will be
able to recognize STALE transitive community and prefer non stale
paths in their forwarding planes (or BGP planes for that matter)
while others will not as well as when both stale and non stale paths
will be present.

Question 1: How do you prevent forwarding loop in such case ?

Question 2: How do you prevent forwarding loop in the case when
customer would have backup connectivity to his sites or connectivity
via different VPN provider yet routers in his site only partially
understand the STALE community and only partially follow the
forwarding rules ?

In general as the rule is about mandating some particular order of
path forwarding selection what is the mechanism in distributed
systems like today's routing to be able to achieve any assurance that
such rule is active and enforced across _all_ routers behind EBGP
PE-CE L3VPN boundaries in customer sites ?

Best regards, R.


-------- Original Message -------- Subject: [Idr]
draft-uttaro-idr-bgp-persistence-00 Date: Sat, 22 Oct 2011 00:23:55
+0200 From: Robert Raszuk<robert@raszuk.net> Reply-To:
robert@raszuk.net To: idr@ietf.org List<idr@ietf.org>

Hi,

I have read the draft and have one question and one observation.

Question:

What is the point of defining DO_NOT_PERSIST community ? In other
words why not having PERSIST community set would not mean the same as
having path marked with DO_NOT_PERSIST.

Observation:

I found the below statement in section 4.2:

o  Forwarding must ensure that the Next Hop to a "stale" route is
viable.

Of course I agree. But since we stating obvious in the forwarding
section I think it would be good to explicitly also state this in
the best path selection that next hop to STALE best path must be
valid.

However sessions especially those between loopbacks do not go down
for no reason. Most likely there is network problem which may have
caused those sessions to go down. It is therefor likely that LDP
session went also down between any of the LSRs in the data path and
that in spite of having the paths in BGP and next hops in IGP the LSP
required for both quoted L2/L3VPN applications is broken. That may
particularly happen when network chooses to use independent control
mode for label allocation.

I would suggest to at least add the recommendation statement to the
document that during best path selection especially for stale paths
a validity of required forwarding paradigm to next hop of stale
paths should be verified.

For example using techniques as described in:
draft-ietf-idr-bgp-bestpath-selection-criteria

Best regards, R.


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


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



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


    

    

  


--------------030002050604080607060202--

From bashandy@cisco.com  Fri Oct 28 11:16:00 2011
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 A8A2021F8A56 for ; Fri, 28 Oct 2011 11:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI8J2ob5jD0g for ; Fri, 28 Oct 2011 11:15:59 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CFA4E21F85B5 for ; Fri, 28 Oct 2011 11:15:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=7593; q=dns/txt; s=iport; t=1319825760; x=1321035360; h=message-id:date:from:mime-version:to:cc:subject; bh=tKQ3O0yHgjwofpktHgAU3KKRDVcLKIrgNOFK1rDvakA=; b=FML9Usc+XEbhIVXk+EDPfJGjiIooBPqjmMrtfEkKxy8GJyZjch4MVkcL Hyl/TgZzKYFfOD5VtY6KPXQJvBFKnN+19yQ8axh8bNivg0a9K1ZIIJcAr xHO/zc3WvvqSQ8p5T7Rd/9NYX0Fs1N3KxFMmKKGNCuR6lCEMJ6B1Di/ei A=;
X-Files: signature.asc : 251
X-IronPort-AV: E=Sophos;i="4.69,419,1315180800";  d="asc'?scan'208,217";a="10979609"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 28 Oct 2011 18:15:59 +0000
Received: from [128.107.163.125] (dhcp-128-107-163-125.cisco.com [128.107.163.125]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9SIFwgG020429; Fri, 28 Oct 2011 18:15:59 GMT
Message-ID: <4EAAF15E.7080505@cisco.com>
Date: Fri, 28 Oct 2011 11:15:58 -0700
From: Ahmed Bashandy 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: idr@ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBADF45C695E1C205FB8A7BFC"
Subject: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-edge-node-frr-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: Fri, 28 Oct 2011 18:16:00 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBADF45C695E1C205FB8A7BFC
Content-Type: multipart/alternative;
 boundary="------------070404080709090307020108"

This is a multi-part message in MIME format.
--------------070404080709090307020108
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

this is a new version of the draft. It just has editorial changes.
=20
I only got one comment from Rob Shakir. His primary concern is that the
draft requires allocating multiple prefixes to each PE to be used as BGP
Next-hops. This may be a problem for deployments with constrained
address space, such as  deployments that do not use private addresses as
BGP next-hops in BGP_free cores
We are working to address Rob's concern

All additional comments are most welcomed

Thanks

Ahmed


-------- Original Message --------
Subject: 	New Version Notification for
draft-bashandy-bgp-edge-node-frr-01.txt
Date: 	Fri, 28 Oct 2011 10:50:31 -0700
From: 	internet-drafts@ietf.org
To: 	bashandy@cisco.com
CC: 	bashandy@cisco.com



A new version of I-D, draft-bashandy-bgp-edge-node-frr-01.txt has been su=
ccessfully submitted by Ahmed Bashandy and posted to the IETF repository.=


Filename:	 draft-bashandy-bgp-edge-node-frr
Revision:	 01
Title:		 Scalable BGP FRR Protection against Edge Node Failure
Creation date:	 2011-10-26
WG ID:		 Individual Submission
Number of pages: 17

Abstract:
Consider a BGP free core scenario. Suppose the edge BGP speakers PE1,
PE2,..., PEn know about a prefix P/p via the external routers CE1,
CE2,..., CEm.  If the edge router PEi crashes or becomes totally
disconnected from the core, it desirable for a penultimate hop route
"P" carrying traffic to the failed edge router PEi to immediate=
ly
restore traffic by re-tunneling packets originally tunneled to PEi
and destined to the prefix P/p to one of the other edge routers that
advertised P/p, say PEj, until BGP re-converges. In doing so, it is
highly desirable to keep the core BGP-free while not imposing
restrictions on external connectivity. Thus (1) a core router should
not be required to learn any BGP prefix, (2) the size of the
forwarding and routing tables in the core routers should be
independent of the number of BGP prefixes,(3) there should be no
special router (or group of routers) that handles restoring traffic,
and (4) there should be no restrictions on what edge routers
advertise what prefixes. For labeled prefixes, (5) the penultimate
hop router must swap the label advertised by the failed edge router
PEi for the prefix P/p with the label advertised for the same prefix
by the edge router PEj before re-tunneling the packet to PEj

                                                                         =
        =20


The IETF Secretariat


--------------070404080709090307020108
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



  

    
  
  
    Hi,

    

    this is a new version of the draft. It just has editorial changes.
    =C2=A0

    I only got one comment from Rob Shakir. His primary concern is that
    the draft requires allocating multiple prefixes to each PE to be
    used as BGP Next-hops. This may be a problem for deployments with
    constrained address space, such as=C2=A0 deployments that do not use
    private addresses as BGP next-hops in BGP_free cores

    We are working to address Rob's concern

    

    All additional comments are most welcomed

    

    Thanks

    

    Ahmed

    

    

    -------- Original Message --------
    

      
        

          Subje=
ct: 
          New Version Notification for
            draft-bashandy-bgp-edge-node-frr-01.txt
        

        

          Date:=
 
          Fri, 28 Oct 2011 10:50:31 -0700
        

        

          From:=
 
          internet-drafts@ietf.org
        

        

          To: <=
/th>
          bashandy@cisco.com
        

        

          CC: <=
/th>
          bashandy@cisco.com
        

      
    

    

    

    
A new version of I-D, draft-bashandy-bgp-edge-node-frr-01.txt ha=
s been successfully submitted by Ahmed Bashandy and posted to the IETF re=
pository.

Filename:	 draft-bashandy-bgp-edge-node-frr
Revision:	 01
Title:		 Scalable BGP FRR Protection against Edge Node Failure
Creation date:	 2011-10-26
WG ID:		 Individual Submission
Number of pages: 17

Abstract:
Consider a BGP free core scenario. Suppose the edge BGP speakers PE1,
PE2,..., PEn know about a prefix P/p via the external routers CE1,
CE2,..., CEm.  If the edge router PEi crashes or becomes totally
disconnected from the core, it desirable for a penultimate hop route
&quot;P&quot; carrying traffic to the failed edge router PEi to i=
mmediately
restore traffic by re-tunneling packets originally tunneled to PEi
and destined to the prefix P/p to one of the other edge routers that
advertised P/p, say PEj, until BGP re-converges. In doing so, it is
highly desirable to keep the core BGP-free while not imposing
restrictions on external connectivity. Thus (1) a core router should
not be required to learn any BGP prefix, (2) the size of the
forwarding and routing tables in the core routers should be
independent of the number of BGP prefixes,(3) there should be no
special router (or group of routers) that handles restoring traffic,
and (4) there should be no restrictions on what edge routers
advertise what prefixes. For labeled prefixes, (5) the penultimate
hop router must swap the label advertised by the failed edge router
PEi for the prefix P/p with the label advertised for the same prefix
by the edge router PEj before re-tunneling the packet to PEj

                                                                         =
        =20


The IETF Secretariat


  


--------------070404080709090307020108--

--------------enigBADF45C695E1C205FB8A7BFC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOqvFe+G19kFA5zIYRAj+sAJ90u5xO+kudG/IgCW7AWJLoEDNfpACfbeAJ
zokO9R8d7USQX0EvU18JyBw=
=l08w
-----END PGP SIGNATURE-----

--------------enigBADF45C695E1C205FB8A7BFC--

From enkechen@cisco.com  Fri Oct 28 13:48:06 2011
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 685FD21F8558 for ; Fri, 28 Oct 2011 13:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.948
X-Spam-Level: 
X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Wjvva3eFO6kH for ; Fri, 28 Oct 2011 13:48:05 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4E08C21F8551 for ; Fri, 28 Oct 2011 13:48:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=1041; q=dns/txt; s=iport; t=1319834884; x=1321044484; h=message-id:date:from:mime-version:to:cc:subject; bh=0bVKOwcoEOZkgPYgVFxmLt8hLRTibikvB5HDhpepQGU=; b=hZvwniQqhF1tc1a/lq8wLkGmi8nu0U85oEJVszXnvDEFr5Q1+ry2HOTJ f2ogfuFfGwK2u2ANTLKiUoOb/iIEYoqERLdtfuVBpFuZRvHIR/YRwu/eW J7kgiD6N7oPrK8C9ClEXd5vS5kpHTmXb4b/y76m/Q41whgDDRI8IJfP6B s=;
X-IronPort-AV: E=Sophos;i="4.69,420,1315180800"; d="scan'208,217";a="11030830"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 28 Oct 2011 20:48:04 +0000
Received: from enkechen-mac.local ([10.155.34.161]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9SKm4dq028323; Fri, 28 Oct 2011 20:48:04 GMT
Message-ID: <4EAB1545.3000201@cisco.com>
Date: Fri, 28 Oct 2011 13:49:09 -0700
From: Enke Chen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: "John G. Scudder" , Susan Hares 
Content-Type: multipart/alternative; boundary="------------080605080806040406010709"
Cc: Keyur Patel , "idr@ietf.org" 
Subject: [Idr] draft-keyur-idr-enhanced-gr-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, 28 Oct 2011 20:48:06 -0000

This is a multi-part message in MIME format.
--------------080605080806040406010709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Sue and John:

We would like to request that the following draft be adopted as an IDR WR document:

      draft-keyur-idr-enhanced-gr-00.txt

It's presented at the last IETF.

Thanks.   -- Enke



--------------080605080806040406010709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    
    
Hi, Sue and John:

We would like to request that the following draft be adopted as an IDR WR document:

     draft-keyur-idr-enhanced-gr-00.txt

It's presented at the last IETF.

Thanks.   -- Enke



  


--------------080605080806040406010709--

From jgs@juniper.net  Fri Oct 28 13:56:26 2011
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 AC05411E808B for ; Fri, 28 Oct 2011 13:56:26 -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 vkws5kAIcEGc for ; Fri, 28 Oct 2011 13:56:26 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id F3DB011E8082 for ; Fri, 28 Oct 2011 13:56:24 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP;  Fri, 28 Oct 2011 13:56:26 PDT
Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 28 Oct 2011 13:51:42 -0700
From: John Scudder 
To: "idr@ietf.org List" 
Date: Fri, 28 Oct 2011 13:51:41 -0700
Thread-Topic: [Idr] Accept draft-wkumari-idr-as0-01.txt  ?
Thread-Index: AcyVs2V23fa/fthQSEeEeBxgw4sVpg==
Message-ID: <14DD6B3A-B114-4F42-B6D0-37CC377D28C5@juniper.net>
References: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net>
In-Reply-To: <7E27D7DD-8A61-43E8-904E-DEDB3B2D2C92@kumari.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Idr] Accept draft-wkumari-idr-as0-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: Fri, 28 Oct 2011 20:56:26 -0000

Folks,

Please send comments to the list prior to the IDR meeting on November 15.

Thanks,

--John

On Oct 27, 2011, at 9:29 AM, Warren Kumari wrote:

> Hello IDRites,
>=20
> I would like to draw your attention to draft-wkumari-idr-as0-01.txt  ( ht=
tp://tools.ietf.org/html/draft-wkumari-idr-as0-01 ) - I am asking that this=
 draft be considered for WG adoption.
>=20
>=20
> I have already received some feedback, mainly suggesting:
>=20
> - Add a text for AS number 0 as a reserved in Aggregator and AS4
> Aggregator attribute
>=20
> - Add text for AS number 0 as a reserved value in communities and
> extended communities. (RFC 1997 and Four-octet AS Specific Extended
> Communities)
>=20
> Also suggested was providing a little more information on what to do it y=
ou do receive a route containing AS0  (more descriptive than just "MUST NOT=
 accept" (for example, stating that it should be "excluded from the Phase 2=
 decision function")).
>=20
> Anyway, I would value your feedback and input.
>=20
> W
>=20
>=20
>=20
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


From jgs@juniper.net  Fri Oct 28 13:56:34 2011
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 412EB1F0C46 for ; Fri, 28 Oct 2011 13:56:34 -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=[AWL=0.000,  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 UMf-BrnfFlio for ; Fri, 28 Oct 2011 13:56:33 -0700 (PDT)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFBA1F0C45 for ; Fri, 28 Oct 2011 13:56:32 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP;  Fri, 28 Oct 2011 13:56:33 PDT
Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 28 Oct 2011 13:51:54 -0700
From: John Scudder 
To: "idr@ietf.org List" 
Date: Fri, 28 Oct 2011 13:51:53 -0700
Thread-Topic: draft-keyur-idr-enhanced-gr-00.txt
Thread-Index: AcyVs2y39olZ1bXNR1OimTEEss8HCA==
Message-ID: <404F0C7A-5866-46AA-BD99-767D865E9FFE@juniper.net>
References: <4EAB1545.3000201@cisco.com>
In-Reply-To: <4EAB1545.3000201@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Keyur P Patel 
Subject: Re: [Idr] draft-keyur-idr-enhanced-gr-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, 28 Oct 2011 20:56:34 -0000

Folks,

Please send comments to the list prior to the IDR meeting on November 15.

Thanks,

--John

On Oct 28, 2011, at 4:49 PM, Enke Chen wrote:

> Hi, Sue and John:
>=20
> We would like to request that the following draft be adopted as an IDR WR=
 document:
>=20
>      draft-keyur-idr-enhanced-gr-00.txt
>=20
> It's presented at the last IETF.
>=20
> Thanks.   -- Enke
>=20


From keyupate@cisco.com  Fri Oct 28 18:54:49 2011
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 40EDD21F8463 for ; Fri, 28 Oct 2011 18:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level: 
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 96cmSzf32Ojp for ; Fri, 28 Oct 2011 18:54:48 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 59BC321F8461 for ; Fri, 28 Oct 2011 18:54:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=keyupate@cisco.com; l=1109; q=dns/txt; s=iport; t=1319853288; x=1321062888; h=date:subject:from:to:message-id:mime-version; bh=ZiP97vfjkeRG1+os7DrwhXXhZ/Nxk3gClXsuD746FVs=; b=Sy5wheGUCZikVsIo7j5VXKf/MxIpPK0Mg2t3KCmMj9j5gCeB6pDKx83P l4gYDMfEjG01VBcqTX0W/1BHe16PiOD0INfJEFwpc3aabJ8qrDxXo6+j7 mtrvuEorK6MshdrUv34zl/5d+Hf0kP8+F0xKQJOQnsvMuX97zZ0Ir6MZW c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAKNcq06rRDoJ/2dsb2JhbABCgk2mH3uBBYFpBQYBAQMSASo6FAELAQIIgRABBAE0hSaCMpYBAZ4AiQMEiAaMCIU2jEk
X-IronPort-AV: E=Sophos;i="4.69,421,1315180800"; d="scan'208,217";a="11093245"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 29 Oct 2011 01:54:47 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9T1slxv007177; Sat, 29 Oct 2011 01:54:47 GMT
Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 28 Oct 2011 18:54:47 -0700
Received: from 10.21.124.171 ([10.21.124.171]) by xmb-sjc-239.amer.cisco.com ([128.107.191.105]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Sat, 29 Oct 2011 01:54:46 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 28 Oct 2011 18:55:23 -0700
From: Keyur Patel 
To: John Scudder , "Rex Fernando (rex)" , , 
Message-ID: 
Thread-Topic: draft-keyupate-idr-bgp-gr-notification-00.txt
Thread-Index: AcyV3dH5lc/eBPTQ+kql8WhTfRu0Uw==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3402672923_27173413"
X-OriginalArrivalTime: 29 Oct 2011 01:54:47.0317 (UTC) FILETIME=[BCB4AC50:01CC95DD]
Subject: [Idr] draft-keyupate-idr-bgp-gr-notification-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: Sat, 29 Oct 2011 01:54:49 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3402672923_27173413
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Sue and John:

We would like to request that the following draft be adopted as an IDR WG
document:

draft-keyupate-idr-bgp-gr-notification-00.txt

It was presented at the IETF in Czech Republic.

Regards,
Keyur


--B_3402672923_27173413
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable



draft-keyupate-idr-bgp-gr-notification-00.txt


Hi Sue and John:



We would like to request that the following draft be adopted as an IDR WG d=
ocument:



draft-keyupate-idr-bgp-gr-notification-00.txt



It was presented at the IETF in Czech Republic.



Regards,

Keyur






--B_3402672923_27173413--


From bashandy@cisco.com  Sun Oct 30 19:16:58 2011
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 1FEBE11E8095; Sun, 30 Oct 2011 19:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I78LY4K4507o; Sun, 30 Oct 2011 19:16:57 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7F23111E808D; Sun, 30 Oct 2011 19:16:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=7334; q=dns/txt; s=iport; t=1320027417; x=1321237017; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=VOoKI9mLcNEBIPw0vZk6zpbV79cz7C8LGwnGIp+r8K8=; b=HX+cLbuWsGypaZm9v9bo0cO2Wceo4VTEW0LwGQjgv2zGvR694aRbbcvG Dj3KNLyI5uNoIIh7n44xrSYTcYtP+E4cFMdj+LQf8pPiBGiJXVWPvleqY CGFgLZOhLQ2e0QnTguNxuZcDSaZ/z1ltbh/Z1DHXVekPDO416t7TGlPGA U=;
X-Files: signature.asc : 251
X-IronPort-AV: E=Sophos;i="4.69,428,1315180800";  d="asc'?scan'208,217";a="10127779"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 31 Oct 2011 02:16:57 +0000
Received: from [10.21.87.231] ([10.21.87.231]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9V2GvQP032262; Mon, 31 Oct 2011 02:16:57 GMT
Message-ID: <4EAE0519.4050409@cisco.com>
Date: Sun, 30 Oct 2011 19:16:57 -0700
From: Ahmed Bashandy 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: idr@ietf.org
References: <20111030232635.4403.33840.idtracker@ietfa.amsl.com>
In-Reply-To: <20111030232635.4403.33840.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5D9E62725BC3D89F6147C3B0"
Cc: "Burjiz Pithawala \(bpithaw\)" , rtgwg@ietf.org
Subject: Re: [Idr] New Version Notification for draft-bashandy-idr-bgp-repair-label-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, 31 Oct 2011 02:16:58 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5D9E62725BC3D89F6147C3B0
Content-Type: multipart/alternative;
 boundary="------------040908010106040905060904"

This is a multi-part message in MIME format.
--------------040908010106040905060904
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This is a draft proposing that an egress PE reroutes traffic, without wai=
ting for BGP or IGP to re-converge, to another pre-calculated egress PE i=
n a BGP-free core when the egress PE detects that the external NH is no l=
onger reachable. Because traffic coming from the core is redirected back =
to the core, we propose using a specially advertised label to make sure t=
hat the traffic does not get re-routed multiple times into the core, thus=
 avoiding loops.

This is a new version of the draft based on comments that we got so far

The primary modification from the previous version is that repairing PEs =
are only egress PEs=20

All comments are most welcomed

Thanks

Ahmed




On 10/30/2011 4:26 PM, internet-drafts@ietf.org wrote:
>
> A new version of I-D, draft-bashandy-idr-bgp-repair-label-03.txt has
> been successfully submitted by Ahmed Bashandy and posted to the IETF
> repository.
>
> Filename:        draft-bashandy-idr-bgp-repair-label
> Revision:        03
> Title:           Scalable, Loop-Free BGP FRR using Repair Label
> Creation date:   2011-10-30
> WG ID:           Individual Submission
> Number of pages: 13
>
> Abstract:
> Consider a BGP free core scenario. Suppose the provider edge BGP
> speakers PE1, PE2,..., PEn know about a prefix P/p via the external
> routers CE1, CE2,..., CEm.  If the PE router PEi loses connectivity to
> the primary path, it is desirable to immediately restore traffic by
> rerouting packets arriving from the core to PEi and destined to the
> prefix P/p to one of the other PE routers that advertised P/p, say PEj,=

> until BGP re-converges. However if the loss of connectivity of PEi to
> the primary path also resulted in the loss of connectivity between PEj
> and CEj, rerouting a packet before the control plane converges may
> result in a loop. In this document, we propose using a repair label for=

> traffic restoration while avoiding loops. We propose advertising the
> "repair" label through BGP.
>
>                                                                        =
         =20
>
>
> The IETF Secretariat
>

--------------040908010106040905060904
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



  
    
  
  
    
This is a draft proposing that an egress PE reroutes t=
raffic, without waiting for BGP or IGP to re-converge, to another pre-cal=
culated egress PE in a BGP-free core when the egress PE detects that the =
external NH is no longer reachable. Because traffic coming from the core =
is redirected back to the core, we propose using a specially advertised l=
abel to make sure that the traffic does not get re-routed multiple times =
into the core, thus avoiding loops.

This is a new version of the draft based on comments that we got so far

The primary modification from the previous version is that repairing PEs =
are only egress PEs=20

All comments are most welcomed

Thanks

Ahmed



    

    

    On 10/30/2011 4:26 PM, internet-drafts@ietf.org wrote:
    

      
      
      New Version Notification
        fordraft-bashandy-idr-bgp-repair-label-03.txt
      
      
A new version of I-D,
          draft-bashandy-idr-bgp-repair-label-03.txt has been
          successfully submitted by Ahmed Bashandy and posted to the
          IETF repository.

          

          Filename:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-basha=
ndy-idr-bgp-repair-label

          Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 03

          Title:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 S=
calable, Loop-Free BGP FRR using Repair
          Label

          Creation date:=C2=A0=C2=A0 2011-10-30

          WG ID:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I=
ndividual Submission

          Number of pages: 13

          

          Abstract:

          Consider a BGP free core scenario. Suppose the provider edge
          BGP

          speakers PE1, PE2,..., PEn know about a prefix P/p via the
          external

          routers CE1, CE2,..., CEm.=C2=A0 If the PE router PEi loses
          connectivity to

          the primary path, it is desirable to immediately restore
          traffic by

          rerouting packets arriving from the core to PEi and destined
          to the

          prefix P/p to one of the other PE routers that advertised P/p,
          say PEj,

          until BGP re-converges. However if the loss of connectivity of
          PEi to

          the primary path also resulted in the loss of connectivity
          between PEj

          and CEj, rerouting a packet before the control plane converges
          may

          result in a loop. In this document, we propose using a repair
          label for

          traffic restoration while avoiding loops. We propose
          advertising the

          &quot;repair&quot; label through BGP.

          

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

          

          

          The IETF Secretariat

        
      

    

  


--------------040908010106040905060904--

--------------enig5D9E62725BC3D89F6147C3B0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOrgUZ+G19kFA5zIYRAhqpAJ9OneGuyz+9VQl5+RBW4tngQcgnRgCZAamF
etQN7RQDva/MaohLjkYQF6Q=
=vl21
-----END PGP SIGNATURE-----

--------------enig5D9E62725BC3D89F6147C3B0--

From internet-drafts@ietf.org  Sun Oct 30 19:42:30 2011
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 F1ED511E80A3; Sun, 30 Oct 2011 19:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.565
X-Spam-Level: 
X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 T2-w-VSmYsFY; Sun, 30 Oct 2011 19:42:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F99111E808C; Sun, 30 Oct 2011 19:42:29 -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: 3.62
Message-ID: <20111031024229.28190.3779.idtracker@ietfa.amsl.com>
Date: Sun, 30 Oct 2011 19:42:29 -0700
Cc: idr@ietf.org
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ipv6-rt-constrain-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: Mon, 31 Oct 2011 02:42:30 -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           : IPv6 Extensions for Route Target Distribution
	Author(s)       : Keyur Patel
                          Robert Raszuk
                          Martin Djernaes
                          Jie Dong
                          Mach(Guoyi) Chen
	Filename        : draft-ietf-idr-bgp-ipv6-rt-constrain-01.txt
	Pages           : 7
	Date            : 2011-10-30

   The current route target distribution specification described in
   RFC4684 defines Route Target NLRIs of maximum length of 12 bytes.
   The IPv6 specific Route Target extended community is defined in
   [RFC5701] as length of 20 bytes.  Since the current specification
   only supports prefixes of maximum length of 12 bytes, the lack of an
   IPv6 specific Route Target reachability information may be a problem
   when an operator wants to use this application in a pure IPv6
   environment.  This document defines an extension that allows BGP to
   exchange longer length IPv6 Route Target prefixes.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ipv6-rt-constrain-01=
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-ipv6-rt-constrain-01.=
txt

From skh@ndzh.com  Mon Oct 31 11:02:25 2011
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 594261F0CAA for ; Mon, 31 Oct 2011 11:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.617
X-Spam-Level: ***
X-Spam-Status: No, score=3.617 tagged_above=-999 required=5 tests=[AWL=0.998,  BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfN5MBjHlN67 for ; Mon, 31 Oct 2011 11:02:25 -0700 (PDT)
Received: from hickoryhill-consulting.com (63-208-161-201.digitalrealm.net [63.208.161.201]) by ietfa.amsl.com (Postfix) with ESMTP id BA5EE1F0C9F for ; Mon, 31 Oct 2011 11:02:24 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; 
Received: from SKHPERSONALLT (unverified [64.112.195.202])  by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 2798475-1945496 for multiple; Mon, 31 Oct 2011 13:02:16 -0500
From: "Susan Hares" 
To: "'IETF IDR'" 
Date: Mon, 31 Oct 2011 14:02:28 -0400
Message-ID: <056701cc97f7$416535d0$c42fa170$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0568_01CC97D5.BA5395D0"
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcyV3dH5lc/eBPTQ+kql8WhTfRu0UwCFeBhw
Content-language: en-us
X-Authenticated-User: skh@ndzh.com 
Cc: 'Susan Hares' , "'John G. Scudder'" 
Subject: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoption as working group draft
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, 31 Oct 2011 18:02:25 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0568_01CC97D5.BA5395D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Folks: 

 

The authors request the adoption of this draft. 

draft-keyupate-idr-bgp-gr-notification-00.txt

 

Comments should be sent to the mailing group by November 15th.

Sue and John


------=_NextPart_000_0568_01CC97D5.BA5395D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

draft-keyupate-idr-bgp-gr-notification-00.txt
Folks: =

 
The authors request the adoption of this draft. 

dra=
ft-keyupate-idr-bgp-gr-notification-00.txt
 
Comments should be sent to the mailing group by November =
15th.

Sue and John

------=_NextPart_000_0568_01CC97D5.BA5395D0--


From enkechen@cisco.com  Mon Oct 31 11:10:22 2011
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 B869F21F8DF3 for ; Mon, 31 Oct 2011 11:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKzK9lnveBAa for ; Mon, 31 Oct 2011 11:10:20 -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 3176D21F8DF1 for ; Mon, 31 Oct 2011 11:10:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=4520; q=dns/txt; s=iport; t=1320084617; x=1321294217; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=N7iT5hSun6+gccEBGZOvwg8ttEArulF3DJl5y3NutY4=; b=XZ6wYaubvMNIyFdk6BbkkB7vu3PWnULyv9EFbikgTG+yZcUo4W9cfO8g AO/SuIZS3ecbvJ2wpjXVifI3rDWv+0cJDhLFkM2J5FvMVI0tcnzMOU1+i A++jZutv3EDVtuKAZ8PxEiHFb5X9I4cNz4ocH+h4/huQxQG1p7hlJMsvx w=;
X-IronPort-AV: E=Sophos;i="4.69,433,1315180800"; d="scan'208,217";a="32278055"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 31 Oct 2011 18:10:16 +0000
Received: from enkechen-mac.local ([10.155.34.161]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9VIAGhe010800;  Mon, 31 Oct 2011 18:10:16 GMT
Message-ID: <4EAEE4CE.8060708@cisco.com>
Date: Mon, 31 Oct 2011 11:11:26 -0700
From: Enke Chen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: idr@ietf.org
References: <056701cc97f7$416535d0$c42fa170$@com>
In-Reply-To: <056701cc97f7$416535d0$c42fa170$@com>
Content-Type: multipart/alternative; boundary="------------060809040409050609080400"
Subject: Re: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoption as working group draft
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, 31 Oct 2011 18:10:22 -0000

This is a multi-part message in MIME format.
--------------060809040409050609080400
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

support.

-- Enke

On 10/31/11 11:02 AM, Susan Hares wrote:
>
> Folks:
>
> The authors request the adoption of this draft.
>
> draft-keyupate-idr-bgp-gr-notification-00.txt
>
> Comments should be sent to the mailing group by November 15^th .
>
> Sue and John
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr


--------------060809040409050609080400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    support.

    

    -- Enke

    

    On 10/31/11 11:02 AM, Susan Hares wrote:
    

      
      
      draft-keyupate-idr-bgp-gr-notification-00.txt
      
      

        
Folks:
          

        
 

        
The
            authors request the adoption
            of this draft. 

            

            draft-keyupate-idr-bgp-gr-notification-00.txt

        
 

        
Comments
            should be sent to the mailing group by November 15th.

            

            Sue and John

      

      

      

      

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


    

    

  


--------------060809040409050609080400--

From bvenkata@cisco.com  Mon Oct 31 18:01:47 2011
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 99ECD1F0C4F for ; Mon, 31 Oct 2011 18:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shNzEKafDi3w for ; Mon, 31 Oct 2011 18:01:47 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 73ADB1F0C40 for ; Mon, 31 Oct 2011 18:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bvenkata@cisco.com; l=4400; q=dns/txt; s=iport; t=1320109306; x=1321318906; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=9nIafvfwuKk7nOwD/1WCCDEUMbWMtiXxKCEOja8JKlg=; b=lCsEAqTqytzkDHlDZTzoYqQIAsu7ZHmTQtQeIKh13ksPKsLg5SKR35YP J7bbmkehfeofBoDrZmbxTSoorfrUmTinqkKBkZBi3A4mu7VKBixJfr50s fKS9OY4W11dPU8kGOvbyq79BElR38zV7oSYa1Supph6rVuozvANAmNR9l E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtgAAINEr05Io8UT/2dsb2JhbABDgk2XFo9TgQWBcgEBAQEDEgEJEQNHEgIBCBEEAQELBhcBBgFFCQgBAQQBCggIGp1lAZ45iCFhBIgEkUCMMQ
X-IronPort-AV: E=Sophos;i="4.69,435,1315180800"; d="scan'208,217";a="2137187"
Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-3.cisco.com with ESMTP; 01 Nov 2011 01:01:44 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA111h98017553; Tue, 1 Nov 2011 01:01:43 GMT
Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 1 Nov 2011 06:31:43 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9831.D213912C"
Date: Tue, 1 Nov 2011 06:31:42 +0530
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt
Thread-Index: AcyV3dH5lc/eBPTQ+kql8WhTfRu0UwCU+v8w
References: 
From: "Balaji Pitta Venkatachalapathy (bvenkata)" 
To: "Keyur Patel (keyupate)" , "John Scudder" , "Rex Fernando (rex)" ,  , 
X-OriginalArrivalTime: 01 Nov 2011 01:01:43.0387 (UTC) FILETIME=[D22CC2B0:01CC9831]
Subject: Re: [Idr] draft-keyupate-idr-bgp-gr-notification-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, 01 Nov 2011 01:01:47 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC9831.D213912C
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Support.

=20

Regards,

Balaji

=20

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of
Keyur Patel (keyupate)
Sent: Friday, October 28, 2011 6:55 PM
To: John Scudder; Rex Fernando (rex); jhaas@juniper.net; idr@ietf.org
Subject: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt

=20

Hi Sue and John:

We would like to request that the following draft be adopted as an IDR
WG document:

draft-keyupate-idr-bgp-gr-notification-00.txt

It was presented at the IETF in Czech Republic.

Regards,
Keyur


------_=_NextPart_001_01CC9831.D213912C
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

draft-keyupate-idr-bgp-gr-notification-00.txt
Support.
 
Regards,
Balaji
 
From:=
 =
idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of =
Keyur Patel (keyupate)
Sent: Friday, October 28, 2011 6:55 =
PM
To: John Scudder; Rex Fernando (rex); jhaas@juniper.net; =
idr@ietf.org
Subject: [Idr] =
draft-keyupate-idr-bgp-gr-notification-00.txt
=

 
Hi Sue and =
John:

We would like to request that the following draft be =
adopted as an IDR WG =
document:

draft-keyupate-idr-bgp-gr-notification-00.txt

It =
was presented at the IETF in Czech =
Republic.

Regards,
Keyur

------_=_NextPart_001_01CC9831.D213912C--

From randy@psg.com  Mon Oct 31 20:57:12 2011
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 C312C11E80F3 for ; Mon, 31 Oct 2011 20:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009,  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 HccYVtzboj+x for ; Mon, 31 Oct 2011 20:57:12 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7502311E80E7 for ; Mon, 31 Oct 2011 20:57:12 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RL5TK-0009U2-85; Tue, 01 Nov 2011 03:57:10 +0000
Date: Tue, 01 Nov 2011 04:57:08 +0100
Message-ID: 
From: Randy Bush 
To: "Susan Hares" 
In-Reply-To: <056701cc97f7$416535d0$c42fa170$@com>
References: <056701cc97f7$416535d0$c42fa170$@com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Cc: IETF IDR , John Scudder 
Subject: Re: [Idr] FW: draft-keyupate-idr-bgp-gr-notification-00.txt - Adoption	as working group draft
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, 01 Nov 2011 03:57:12 -0000

read and support.  as bgp embellishments go, it's less complex than
many.

randy

From jeff.tantsura@ericsson.com  Mon Oct 31 20:59:39 2011
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 34EDF11E8101 for ; Mon, 31 Oct 2011 20:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  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 Pfo5Tm5u1Koc for ; Mon, 31 Oct 2011 20:59:38 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 916A711E80DB for ; Mon, 31 Oct 2011 20:59:38 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pA13xbWl012882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Oct 2011 22:59:37 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 31 Oct 2011 23:59:37 -0400
From: Jeff Tantsura 
To: Keyur Patel 
Date: Mon, 31 Oct 2011 23:59:24 -0400
Thread-Topic: [Idr] draft-keyupate-idr-bgp-gr-notification-00.txt
Thread-Index: AcyYSqutixatnGS8TGKoHTJIe79xNQ==
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "jhaas@juniper.net" , "idr@ietf.org" 
Subject: Re: [Idr] draft-keyupate-idr-bgp-gr-notification-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, 01 Nov 2011 03:59:39 -0000

WWVzL3N1cHBvcnQNCg0KUmVnYXJkcywNCkplZmYNCg0KT24gT2N0IDI4LCAyMDExLCBhdCAxODo1
NSwgIktleXVyIFBhdGVsIiA8a2V5dXBhdGVAY2lzY28uY29tPG1haWx0bzprZXl1cGF0ZUBjaXNj
by5jb20+PiB3cm90ZToNCg0KSGkgU3VlIGFuZCBKb2huOg0KDQpXZSB3b3VsZCBsaWtlIHRvIHJl
cXVlc3QgdGhhdCB0aGUgZm9sbG93aW5nIGRyYWZ0IGJlIGFkb3B0ZWQgYXMgYW4gSURSIFdHIGRv
Y3VtZW50Og0KDQpkcmFmdC1rZXl1cGF0ZS1pZHItYmdwLWdyLW5vdGlmaWNhdGlvbi0wMC50eHQN
Cg0KSXQgd2FzIHByZXNlbnRlZCBhdCB0aGUgSUVURiBpbiBDemVjaCBSZXB1YmxpYy4NCg0KUmVn
YXJkcywNCktleXVyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGlldGYub3JnPG1haWx0bzpJZHJAaWV0Zi5vcmc+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K