From stephane.litkowski@orange.com Mon Oct 1 01:55:57 2012 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 3407921F85C7 for ; Mon, 1 Oct 2012 01:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfL3oNPlBM5I for ; Mon, 1 Oct 2012 01:55:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E782C21F84E2 for ; Mon, 1 Oct 2012 01:55:55 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 4485218C1D4; Mon, 1 Oct 2012 10:55:54 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 26696238075; Mon, 1 Oct 2012 10:55:54 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.64.14.45]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 1 Oct 2012 10:55:53 +0200 From: To: Shane Amante Date: Mon, 1 Oct 2012 10:55:52 +0200 Thread-Topic: [Idr] New Version Notification for draft-ga-idr-as-migration-00.txt Thread-Index: Ac2dIMX2lN8Esn8fT9KxhmFvOAa+mgCkSncg Message-ID: <8955_1349081754_50695A9A_8955_18926_1_EEE55384044474429A926C625D0FCC81041CCF1527@PUEXCB2F.nanterre.francetelecom.fr> References: <20120924130811.20935.26346.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961AA5@PRVPEXVS15.corp.twcable.com> <18209_1348748389_50644465_18209_14333_1_EEE55384044474429A926C625D0FCC81041C96CC71@PUEXCB2F.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.1.81517 Cc: "idr@ietf.org" , "George, Wes" Subject: Re: [Idr] New Version Notification for draft-ga-idr-as-migration-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 08:55:57 -0000 Hi Shane, Regarding diagrams, I was thinking of putting a figure in paragraph =A72 to= display how Ases are connected (it's clearly explained in text, but when r= eading, I needed to reread to remember who is what (and finally I drawn a f= igure by myself :). For feature effect on ASPATH, it's clear with current diagrams and text. =20 Regards, Stephane -----Message d'origine----- De : Shane Amante [mailto:shane@castlepoint.net]=20 Envoy=E9 : vendredi 28 septembre 2012 04:27 =C0 : LITKOWSKI Stephane DTF/DERX Cc : George, Wes; idr@ietf.org Objet : Re: [Idr] New Version Notification for draft-ga-idr-as-migration-00= .txt Hi Stephane, On Sep 27, 2012, at 6:19 AM, stephane.litkowski@orange.com wrote: > Hi Wes, and Shane, >=20 > Good idea to describe such migration situations and required features, as= you mention, not all implementations have these features. > I pretty agree on what is described but I think more diagrams would be he= lpful to clarify. Could you clarify what more diagrams might help with? We tried to simplify= the diagram to depict the effects on the AS_PATH attribute as it traverse = ASN's with these features enabled. Hopefully, we struck the right balance = there, although suggestions are welcome on how we could improve them. > The main point is that today you are only taking into account (but it's j= ust a first shot of draft :) ) the AS merge case, but AS renumbering case i= s also very interresting (we done it :) ) as it may require the "allow-as i= n" or "as-loop" feature and the scenario is a bit difference as you have to= manage inter AS gateways (old and new AS). > It would be helpful to have the draft as PS in order to have such feature= s as MUST or SHOULD within BGP implementations. That's a good point. Due to the short time we had to write & publish this = draft, we only could document what's in the current draft. I do plan to ad= d some other ASN migration features in a next rev of this draft, but had no= t considered those two. Thanks for the suggestion; we'll see what we can d= o.=20=20 > PS : Being able to change AS number in router configuration without=20 > deleting all BGP config would be helpful also :) Fortunately, some vendors got this right.=20=20 -shane > Best Regards, >=20 > Stephane >=20 >=20 > -----Message d'origine----- > De : idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] De la part de=20 > George, Wes Envoy=E9 : lundi 24 septembre 2012 15:11 =C0 : idr@ietf.org C= c=20 > : shane@castlepoint.net Objet : [Idr] FW: New Version Notification for=20 > draft-ga-idr-as-migration-00.txt >=20 > New draft for your review. This is related to a discussion we've been hav= ing in SIDR, but since this procedure is not specific to SIDR, we thought i= t best to document the procedure and features used during an ASN migration = here, and then SIDR will need to simply determine the best way to support t= his. >=20 > This is currently an informational ID, but could potentially be a PS as w= ell. >=20 > Thanks, >=20 > Wes George and Shane Amante >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, September 24, 2012 9:08 AM > To: George, Wes > Cc: shane@level3.net > Subject: New Version Notification for draft-ga-idr-as-migration-00.txt >=20 >=20 > A new version of I-D, draft-ga-idr-as-migration-00.txt has been successfu= lly submitted by Wesley George and posted to the IETF repository. >=20 > Filename: draft-ga-idr-as-migration > Revision: 00 > Title: Autonomous System (AS) Migration Features and Their Effe= cts on the BGP AS_PATH Attribute > Creation date: 2012-09-24 > WG ID: Individual Submission > Number of pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-ga-idr-as-migr= ation-00.txt > Status: http://datatracker.ietf.org/doc/draft-ga-idr-as-migration > Htmlized: http://tools.ietf.org/html/draft-ga-idr-as-migration-00 >=20 >=20 > Abstract: > This draft discusses common methods of managing an ASN migration > using some BGP features that while commonly-used are not formally > part of the BGP4 protocol specification and may be vendor-specific in > exact implementation. It is necessary to document these de facto > standards to ensure that they are properly supported in BGPSec. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From shane@castlepoint.net Mon Oct 1 19:22:19 2012 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 B93A51F0D44; Mon, 1 Oct 2012 19:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlBgrm95c3rB; Mon, 1 Oct 2012 19:22:19 -0700 (PDT) Received: from mail.tcb.net (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 191C91F0D5B; Mon, 1 Oct 2012 19:22:19 -0700 (PDT) Received: from mbpw.castlepoint.net (216-160-173-224.hlrn.qwest.net [216.160.173.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id DD96D430; Mon, 1 Oct 2012 20:22:15 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Shane Amante In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F62BEEFD1A@Hermes.columbia.ads.sparta.com> Date: Mon, 1 Oct 2012 20:22:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <21CAAAC9-79D3-460D-BEC2-F32742AD0E44@castlepoint.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F62BEEFD1A@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1498) Cc: "idr@ietf.org List" , "sidr@ietf.org list" Subject: Re: [Idr] [sidr] comments on recent as migration drafts (draft-ga-idr-as-migration-00) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 02:22:19 -0000 Sandy, Adding IDR to response, since draft-ga-idr-as-migration-00 was submitted = to IDR. Trimming down to parts only relevant to = draft-ga-idr-as-migration-00. Please see below. On Sep 27, 2012, at 7:40 AM, "Murphy, Sandra" = wrote: > Speaking as regular ol' member. >=20 > Some comments about these drafts. [--snip--] > In the idr-as-migration draft, from the discussion it appears that the = implementation of the local-as feature on the PE router in AS supports = the local-as as something like an ebgp session inside the router. (like = it adds the old 300 ASN on AS_PATHs sent over ibgp sessions to AS 200 = neighbors). Am I understanding the examples correctly? I believe you are referring to Section 3, "Local AS". You are correct. Obviously, the implementers would have an authoritative answer to your = question, but I believe that the legacy ASN (AS 300) is actually applied = before the Adj-RIB-In. One important point to keep in mind is that the same PE will also have = eBGP sessions with other eBGP neighbors, (which may or may not be using = these AS migration features _outbound_). Thus, the easiest thing to = implement would be tacking on the legacy AS as the eBGP route is learned = and before it hits the Adj-RIB-In. This way, if it's selected as a = best-path, BGP can easily propagate that route "as-is" towards both iBGP = and other eBGP neighbors. > The goal is for the AS_PATH length to be the same length in the = migration interval as it was before migration. Does it matter if that = effect is accomplished some other way than the knobs currently = implemented? IE the local-as knob has a side effect of getting the 300 = ASN into the AS_PATH to ibgp neighbors so the second knob no-prepend = makes that go away. Do you need both behaviors -- local-as AND local-as = + no-prepend? Yes. Perhaps there is some confusion in the current draft talking about = the two knobs independently? In reality, the *only* behavior we want is = achieved through the combination of both local-as + no-prepend, in Cisco = IOS. If it makes you feel any better, JUNOS makes you also configure = two, separate (but related) knobs to get this behavior: "local-as = private", in the case of inbound eBGP updates. :-) > Would it be OK if the side effect did not happen and you got to the = no-increase-in-path-length goal without needing the no-prepend knob? That's not possible. IOW, the only way to achieve the = "no-increase-in-path-length goal" is to enable "no-prepend" in IOS or = "private" in JUNOS. I suspect that vendors (and, operators) will not be = clamoring to change the existing configuration of AS migration features = this late in the game, i.e.: to just configure them more simply with = just one keyword in the CLI ... > wrt the replace-as technique. The text says that "only the historical = (or, legacy) AS will be prepended in the outbound BGP UPDATE toward the = customer's network". But the example says "After ISP A' changes PE-1 to = include the "Replace AS" feature, CE-1 would receive an AS_PATH of: 200 = 400. " That is indeed "the same AS_PATH length pre-AS migration" as the = text says, which accomplishes that goal, but it would require = configuration of the CE router to accept a first-as that was different = from the one used in the OPEN. I suspect that's a typo, that is after = using replace-as the AS_PATH toward the CE would be "300 400". But it = is an important point so I'd like to make sure. You are correct, that is a typo. Thank you for finding that. We will = fix the text to be as follows in the next rev of the draft: ---snip--- By default, without "Replace AS" enabled, CE-1 would see an AS_PATH of: 300 200 400, which is artificially lengthened by the ASN Migration. After ISP A' changes PE-1 to include the "Replace AS" feature, CE-1 would receive an AS_PATH of: 300 400, which is the same AS_PATH length pre-AS migration. ---snip--- Thanks for your review. -shane= From shane@castlepoint.net Mon Oct 1 19:32:15 2012 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 E83961F0D44; Mon, 1 Oct 2012 19:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-rcuvCsoyyj; Mon, 1 Oct 2012 19:32:14 -0700 (PDT) Received: from mail.tcb.net (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1F89B1F0D5B; Mon, 1 Oct 2012 19:32:14 -0700 (PDT) Received: from mbpw.castlepoint.net (216-160-173-224.hlrn.qwest.net [216.160.173.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 6A75F430; Mon, 1 Oct 2012 20:32:11 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Shane Amante In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F62BEEFF04@Hermes.columbia.ads.sparta.com> Date: Mon, 1 Oct 2012 20:32:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F62BEEFD1A@Hermes.columbia.ads.sparta.com>, <2671C6CDFBB59E47B64C10B3E0BD5923602AB34B@PRVPEXVS15.corp.twcable.com> <24B20D14B2CD29478C8D5D6E9CBB29F62BEEFF04@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1498) Cc: "idr@ietf.org List" , Wes George , "sidr@ietf.org list" Subject: Re: [Idr] [sidr] comments on recent as migration drafts (draft-ga-idr-as-migration-00) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 02:32:15 -0000 Sandy, Adding IDR to this response, as well. Please see below. On Sep 27, 2012, at 5:56 PM, "Murphy, Sandra" = wrote: > wrt: >=20 >>> In the idr-as-migration draft, from the discussion it appears that = the >>> implementation of the local-as feature on the PE router in AS = supports >>> the local-as as something like an ebgp session inside the router. = (like >>> it adds the old 300 ASN on AS_PATHs sent over ibgp sessions to AS = 200 >>> neighbors). Am I understanding the examples correctly? >> [WEG] Not exactly no. There's no additional internal eBGP session = between the=20 >> two ASNs on the PE, and remember that the PE has been reconfigured to = be in=20 >> the retained AS, not the legacy one, so this local-as and its related = switches are=20 >> used on the PE-CE sessions and their associated updates, not PE-PE. = All it's=20 >> doing is overriding the values from the global config that would = normally be=20 >> used to populate "MY ASN" and "AS_PATH" when generating BGP messages=20= >> to a specific neighbor. >=20 >=20 > No, I did not mean to suggest that there was an actual ebgp session. = I think maybe I was reading the replace-as example incorrectly. I am = not sure what the AS_PATH is when it is transmitted between PE1 and PE2 = and it looked like PE1 might be adding ASNs to the AS_PATH it sent over = the ibgp session to PE2. See my previous reply, but in short I believe that AS_PATH modifications = are, in this case, most likely made at the eBGP neighbor (where these AS = migration configurations are applied), since that isolates = modifications/state/etc. wrt the AS_PATH attribute to a single eBGP = neighbor. Of course, implementors should weigh-in if that is incorrect. = :-) =20 >>> from the one used in the OPEN. I suspect that's a typo, that is = after >>> using replace-as the AS_PATH toward the CE would be "300 400". But = it >>> is an important point so I'd like to make sure. >> [WEG] I think you're right that it's a typo, I'll doublecheck with my = co-author. > >> message. If the check determines this is not the case, the Error >> Subcode MUST be set to Malformed AS_PATH." >> I don't know if most common implementations perform this check. In = fact,=20 >> that's why I point out that the question needs to be answered as far = as path=20 >> validation is concerned - does the ASN of the established = neighborship have=20 >> to match the AS_Path or PATH_signatures or does it not matter as long = as the=20 >> signatures are all valid? Does that MAY need to be a MUST in BGPSec = land? >=20 > =46rom = http://www.cisco.com/en/US/docs/ios/12_3t/ip_route/command/reference/ip2_b= 1gt.html#wp1080615, "bgp enforce-first-as" default is enabled and it = means > To configure a router to deny an update received from an external BGP = (eBGP) peer that does not list its autonomous system (AS) number at the = beginning of the AS_PATH in the incoming update, use the bgp = enforce-first-as command in router configuration mode. >=20 > I think this is already a MUST in the protocol because the protocol = makes sure the AS listed are the ones that the packet came through. If = the update came from the neighbor and the first AS in the path is not = the neighbor's AS, then the validation will fail. (Unless the neighbor = has the keys to two ASs and uses an AS other than is used in the OPEN = packet. It's all about the keys.) WRT the above, "bgp enforce-first-as" ... as you pointed out there was a = typo in Section 4, "Replace AS", of draft-ga-idr-as-migration-00. The = last paragraph of that section should read: ---snip--- By default, without "Replace AS" enabled, CE-1 would see an AS_PATH of: 300 200 400, which is artificially lengthened by the ASN Migration. After ISP A' changes PE-1 to include the "Replace AS" feature, CE-1 would receive an AS_PATH of: 300 400, which is the same AS_PATH length pre-AS migration. ---snip---=20 And, in that case, even if/when the "bgp enforce-first-as" knob is = enabled at the CE router, (CE-1 in the diagram in the draft), then the = CE router is *still* going to receive AS 300 as the first AS in the = AS_PATH, even after the ISP A' changes their PE router to enable = 'replace-as'. Thus, this should not conflict with the "bgp = enforce-first-as" knob. Apologies for the typo. We'll fix in the next = rev. Thanks, -shane= From ietfc@btconnect.com Tue Oct 2 07:47:11 2012 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 205AF21F850D for ; Tue, 2 Oct 2012 07:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FAKE_REPLY_C=2.012, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKtl5zhIf4bp for ; Tue, 2 Oct 2012 07:47:10 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 276EB21F84FF for ; Tue, 2 Oct 2012 07:47:09 -0700 (PDT) Received: from mail237-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 14:47:09 +0000 Received: from mail237-va3 (localhost [127.0.0.1]) by mail237-va3-R.bigfish.com (Postfix) with ESMTP id 34B21D00154; Tue, 2 Oct 2012 14:47:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I542M1432I1418Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh172cdfhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h304l1155h) Received: from mail237-va3 (localhost.localdomain [127.0.0.1]) by mail237-va3 (MessageSwitch) id 1349189227504774_14872; Tue, 2 Oct 2012 14:47:07 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.254]) by mail237-va3.bigfish.com (Postfix) with ESMTP id 6C41F180047; Tue, 2 Oct 2012 14:47:07 +0000 (UTC) Received: from AM2PRD0710HT002.eurprd07.prod.outlook.com (157.56.249.213) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 14:46:58 +0000 Received: from DB3PRD0410HT003.eurprd04.prod.outlook.com (157.56.252.21) by pod51017.outlook.com (10.255.165.37) with Microsoft SMTP Server (TLS) id 14.16.207.9; Tue, 2 Oct 2012 14:46:55 +0000 Message-ID: <03ec01cda0ac$ca45bf00$4001a8c0@gateway.2wire.net> From: t.petch To: , , , RFC Errata System Date: Tue, 2 Oct 2012 15:46:49 +0100 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-Originating-IP: [157.56.252.21] X-FOPE-CRA-Verdict: 157.56.249.213$juniper.net%12218%4%btconnect.com%False%True%0$ X-OriginatorOrg: btconnect.com Cc: shtyagi@microsoft.com, idr@ietf.org Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) 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, 02 Oct 2012 14:47:11 -0000 Got a too many recipients bounce on this so trying again with fewer. Tom Petch ----- Original Message ----- From: "t.petch" To: ; ; ; ; ; ; ; "RFC Errata System" Cc: ; ; Sent: Tuesday, October 02, 2012 2:41 P From the Original Text, I infer that this refers to OpenSent, when event 18 occurs. The Notes say "HoldTimer should only be used to control time in between BGP packets. " This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as well as an OPEN) so the timer should be running. "Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state." Well, it will lead to Active state (p.59) - that is what the text says - and event 10, HoldTimer expires, will then take you to Idle state (p.63). The expectation is that the HoldTimer has been set to a large value, 4 minutes, which is much greater than the ConnectRetryTimer (90s) and it is the expiry of the latter that should take you out of Active state to Connect and thence to OpenSent when the HoldTimer will be restarted. Note that the receipt of a KEEPALIVE (event 26) also takes you from Active to Idle - I think that the two cases are similar, that the BGP connection did not reach second base. You are in trouble either way and back to Idle is the safe thing to do. Of course, if you ignore that advice to set the HoldTimer to a large value - you have yet to receive an OPEN and so do not know what value will be acceptable to the peer - and set it instead to 3s, then yes, you will get back to Idle more often than is desirable. Nowadays, there is a greater wish to keep BGP connections up, compared to when we wrote RFC4271, but I think that, in this case, there is nothing worth keeping up and going back to Idle is the right thing to do. (I am not sure what the best distribution for this is so I have used 'Reply All' but expect that that should be trimmed soon - um yes, MUST be trimmed:-(. Tom Petch > > > ----- Original Message ----- > From: "RFC Errata System" > To: ; ; ; > ; ; ; > > Cc: ; ; > Sent: Wednesday, September 26, 2012 10:06 AM > Subject: [Idr] [Technical Errata Reported] RFC4271 (3366) > > > > > > The following errata report has been submitted for RFC4271, > > "A Border Gateway Protocol 4 (BGP-4)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3366 > > > > -------------------------------------- > > Type: Technical > > Reported by: Shashank Tyagi > > > > Section: 8.2.2 > > > > Original Text > > ------------- > > If a TcpConnectionFails event (Event 18) is received, the local > > system: > > > > - closes the BGP connection, > > > > - restarts the ConnectRetryTimer, > > > > - continues to listen for a connection that may be initiated > by > > the remote BGP peer, and > > > > - changes its state to Active. > > > > Corrected Text > > -------------- > > If a TcpConnectionFails event (Event 18) is received, the local > > system: > > > > - closes the BGP connection, > > > > - sets the HoldTimer to 0, > > > > - restarts the ConnectRetryTimer, > > > > - continues to listen for a connection that may be initiated > by > > the remote BGP peer, and > > > > - changes its state to Active. > > > > Notes > > ----- > > HoldTimer should only be used to control time in between BGP packets. > > Also in this case it can lead to case in ACTIVE state where HoldTimer > expires before the ConnectRetryTimer leading to IDLE state. > > > > 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. > > > > -------------------------------------- > > RFC4271 (draft-ietf-idr-bgp4-26) > > -------------------------------------- > > Title : A Border Gateway Protocol 4 (BGP-4) > > Publication Date : January 2006 > > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > > Category : DRAFT STANDARD > > Source : Inter-Domain Routing > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > From ietfc@btconnect.com Tue Oct 2 09:06:13 2012 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 3129C21F845F for ; Tue, 2 Oct 2012 09:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.295 X-Spam-Level: X-Spam-Status: No, score=-3.295 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti1ZWq7kdUZ3 for ; Tue, 2 Oct 2012 09:06:12 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 77A1921F8567 for ; Tue, 2 Oct 2012 09:06:11 -0700 (PDT) Received: from mail42-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 16:06:10 +0000 Received: from mail42-va3 (localhost [127.0.0.1]) by mail42-va3-R.bigfish.com (Postfix) with ESMTP id 9DF8D420071; Tue, 2 Oct 2012 16:06:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zz9371I542M1432I1418I4015Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh172cdfhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h304l1155h) Received: from mail42-va3 (localhost.localdomain [127.0.0.1]) by mail42-va3 (MessageSwitch) id 1349193968562810_11746; Tue, 2 Oct 2012 16:06:08 +0000 (UTC) Received: from VA3EHSMHS038.bigfish.com (unknown [10.7.14.241]) by mail42-va3.bigfish.com (Postfix) with ESMTP id 8388B4004F; Tue, 2 Oct 2012 16:06:08 +0000 (UTC) Received: from DBXPRD0710HT004.eurprd07.prod.outlook.com (157.56.253.197) by VA3EHSMHS038.bigfish.com (10.7.99.48) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 16:06:04 +0000 Received: from DB3PRD0410HT004.eurprd04.prod.outlook.com (157.56.252.21) by pod51017.outlook.com (10.255.79.167) with Microsoft SMTP Server (TLS) id 14.16.207.9; Tue, 2 Oct 2012 16:06:01 +0000 Message-ID: <04d601cda0b7$d70b1720$4001a8c0@gateway.2wire.net> From: t.petch To: Shashank Tyagi , , , , RFC Errata System References: <20120926090655.84AD3B1E002@rfc-editor.org> <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> Date: Tue, 2 Oct 2012 17:05:09 +0100 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-Originating-IP: [157.56.252.21] X-FOPE-CRA-Verdict: 157.56.253.197$juniper.net%12218%4%btconnect.com%False%True%0$ X-OriginatorOrg: btconnect.com Cc: idr@ietf.org Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) 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, 02 Oct 2012 16:06:13 -0000 Shashank How come you can send a message with so many recipients when I cannot:-( Ah well, ... ----- Original Message ----- From: "Shashank Tyagi" To: "t.petch" ; ; ; ; ; ; ; ; "RFC Errata System" Cc: ; Sent: Tuesday, October 02, 2012 2:59 PM Hi Tom, Thanks for your reply. Yes it refers to OpenSent state sorry forgot to mention that. Few comments: -In OpenSent the KEEPALIVE has not been sent, only the Open message has been sent. So there would be no receipt of KEEPALIVE. Right, you are confusing me:-( Your proposed change was to set the HoldTimer to 0 when transitioning from OpenSent state to Active which made me think that a KEEPALIVE had been sent and the HoldTimer could be running in OpenSent and I thought I had found such a case in the FSM this morning. Looking again, I cannot find it so assume that no KEEPALIVE has been sent (I was probably reading OpenConfirm). What then is your suggested change for the receipt of event 18 in OpenSent? To stop the HoldTimer if it is running? To ensure that the next use of the HoldTimer has a zero value and so is not started? Or what? The FSM is intended to be robust in the event of all possibilities, including implementation errors, with the default being, when something completely impossible happens, go back to Idle state. In fact, there are an awful lot of corner cases arising out of such as connection collisions, of data being buffered in the TCP stack when BGP thinks there is no connection, TCP connection dropping and either noone noticing or restarting etc so even a perfect implementation can do some strange things. If, thus, the HoldTimer expires in Active state, the only thing to do IMHO is to revert to Idle (and call your software supplier if you are sure it cannot happen:-) - as I said before, the expectation is that the ConnectRetryTimer will expire first taking it back to OpenSent. Tom Petch -Also when moving from OPENSENT to ACTIVE in case of TCP failure the rfc says to close the BGP connection. Why should the HoldTimer be running without a BGP connection? Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 7:12 PM To: yakov@juniper.net; tony.li@tony.li; skh@nexthop.com; stbryant@cisco.com; adrian@olddog.co.uk; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: Shashank Tyagi; rfc-editor@rfc-editor.org; idr@ietf.org Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) >From the Original Text, I infer that this refers to OpenSent, when event 18 occurs. The Notes say "HoldTimer should only be used to control time in between BGP packets. " This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as well as an OPEN) so the timer should be running. "Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state." Well, it will lead to Active state (p.59) - that is what the text says - and event 10, HoldTimer expires, will then take you to Idle state (p.63). The expectation is that the HoldTimer has been set to a large value, 4 minutes, which is much greater than the ConnectRetryTimer (90s) and it is the expiry of the latter that should take you out of Active state to Connect and thence to OpenSent when the HoldTimer will be restarted. Note that the receipt of a KEEPALIVE (event 26) also takes you from Active to Idle - I think that the two cases are similar, that the BGP connection did not reach second base. You are in trouble either way and back to Idle is the safe thing to do. Of course, if you ignore that advice to set the HoldTimer to a large value - you have yet to receive an OPEN and so do not know what value will be acceptable to the peer - and set it instead to 3s, then yes, you will get back to Idle more often than is desirable. Nowadays, there is a greater wish to keep BGP connections up, compared to when we wrote RFC4271, but I think that, in this case, there is nothing worth keeping up and going back to Idle is the right thing to do. (I am not sure what the best distribution for this is so I have used 'Reply All' but expect that that should be trimmed soon). Tom Petch ----- Original Message ----- From: "RFC Errata System" To: ; ; ; ; ; ; Cc: ; ; Sent: Wednesday, September 26, 2012 10:06 AM Subject: [Idr] [Technical Errata Reported] RFC4271 (3366) > > The following errata report has been submitted for RFC4271, "A Border > Gateway Protocol 4 (BGP-4)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3366 > > -------------------------------------- > Type: Technical > Reported by: Shashank Tyagi > > Section: 8.2.2 > > Original Text > ------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Corrected Text > -------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - sets the HoldTimer to 0, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Notes > ----- > HoldTimer should only be used to control time in between BGP packets. > Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state. > > 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. > > -------------------------------------- > RFC4271 (draft-ietf-idr-bgp4-26) > -------------------------------------- > Title : A Border Gateway Protocol 4 (BGP-4) > Publication Date : January 2006 > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > Category : DRAFT STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG > From Shashank.Tyagi@microsoft.com Tue Oct 2 06:59:27 2012 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 999AF21F84B2 for ; Tue, 2 Oct 2012 06:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om6J2GBmOqBy for ; Tue, 2 Oct 2012 06:59:26 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1721F8496 for ; Tue, 2 Oct 2012 06:59:26 -0700 (PDT) Received: from mail118-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 13:59:25 +0000 Received: from mail118-co1 (localhost [127.0.0.1]) by mail118-co1-R.bigfish.com (Postfix) with ESMTP id CE702980115; Tue, 2 Oct 2012 13:59:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz9371I542M1432I1418I4015Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh172cdfhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h) Received-SPF: pass (mail118-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shashank.Tyagi@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail118-co1 (localhost.localdomain [127.0.0.1]) by mail118-co1 (MessageSwitch) id 1349186364192699_31844; Tue, 2 Oct 2012 13:59:24 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.245]) by mail118-co1.bigfish.com (Postfix) with ESMTP id 2587D840058; Tue, 2 Oct 2012 13:59:24 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 13:59:21 +0000 Received: from SINEX14HUBC401.southpacific.corp.microsoft.com (157.60.220.215) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 2 Oct 2012 13:59:13 +0000 Received: from SINEX14MBXC401.southpacific.corp.microsoft.com ([169.254.1.140]) by SINEX14HUBC401.southpacific.corp.microsoft.com ([157.60.220.215]) with mapi id 14.02.0309.003; Tue, 2 Oct 2012 13:59:09 +0000 From: Shashank Tyagi To: t.petch , "yakov@juniper.net" , "tony.li@tony.li" , "skh@nexthop.com" , "stbryant@cisco.com" , "adrian@olddog.co.uk" , "shares@ndzh.com" , "jgs@juniper.net" , RFC Errata System Thread-Topic: [Idr] [Technical Errata Reported] RFC4271 (3366) Thread-Index: AQHNm8bsE8GH85SgyUCDhjNPddrFsJemEEpsgAACBJA= Date: Tue, 2 Oct 2012 13:59:08 +0000 Message-ID: References: <20120926090655.84AD3B1E002@rfc-editor.org> <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> In-Reply-To: <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 131.107.125.8$juniper.net%12218%4%microsoft.com%False%True%0$btconnect.com%0%1%microsoft.com%False%False%0$ X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Tue, 02 Oct 2012 10:15:53 -0700 Cc: "idr@ietf.org" , "rfc-editor@rfc-editor.org" Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) 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, 02 Oct 2012 14:00:42 -0000 Hi Tom, Thanks for your reply. Yes it refers to OpenSent state sorry = forgot to mention that. Few comments: -In OpenSent the KEEPALIVE has not been sent, only the Open message has bee= n sent. So there would be no receipt of KEEPALIVE.=20 -Also when moving from OPENSENT to ACTIVE in case of TCP failure the rfc sa= ys to close the BGP connection. Why should the HoldTimer be running without= a BGP connection? Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com]=20 Sent: Tuesday, October 02, 2012 7:12 PM To: yakov@juniper.net; tony.li@tony.li; skh@nexthop.com; stbryant@cisco.com= ; adrian@olddog.co.uk; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: Shashank Tyagi; rfc-editor@rfc-editor.org; idr@ietf.org Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) >From the Original Text, I infer that this refers to OpenSent, when event 18 occurs. The Notes say "HoldTimer should only be used to control time in between BGP packets. " This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as we= ll as an OPEN) so the timer should be running. "Also in this case it can lead to case in ACTIVE state where HoldTimer expi= res before the ConnectRetryTimer leading to IDLE state." Well, it will lead to Active state (p.59) - that is what the text says - an= d event 10, HoldTimer expires, will then take you to Idle state (p.63). The expectation is that the HoldTimer has been set to a large value, 4 minu= tes, which is much greater than the ConnectRetryTimer (90s) and it is the e= xpiry of the latter that should take you out of Active state to Connect and= thence to OpenSent when the HoldTimer will be restarted. Note that the receipt of a KEEPALIVE (event 26) also takes you from Active = to Idle - I think that the two cases are similar, that the BGP connection d= id not reach second base. You are in trouble either way and back to Idle i= s the safe thing to do. Of course, if you ignore that advice to set the HoldTimer to a large value = - you have yet to receive an OPEN and so do not know what value will be acc= eptable to the peer - and set it instead to 3s, then yes, you will get back= to Idle more often than is desirable. Nowadays, there is a greater wish to keep BGP connections up, compared to w= hen we wrote RFC4271, but I think that, in this case, there is nothing wort= h keeping up and going back to Idle is the right thing to do. (I am not sure what the best distribution for this is so I have used 'Reply= All' but expect that that should be trimmed soon). Tom Petch ----- Original Message ----- From: "RFC Errata System" To: ; ; ; ; ; ; Cc: ; ; Sent: Wednesday, September 26, 2012 10:06 AM Subject: [Idr] [Technical Errata Reported] RFC4271 (3366) > > The following errata report has been submitted for RFC4271, "A Border=20 > Gateway Protocol 4 (BGP-4)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4271&eid=3D3366 > > -------------------------------------- > Type: Technical > Reported by: Shashank Tyagi > > Section: 8.2.2 > > Original Text > ------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Corrected Text > -------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - sets the HoldTimer to 0, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Notes > ----- > HoldTimer should only be used to control time in between BGP packets. > Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. > > -------------------------------------- > RFC4271 (draft-ietf-idr-bgp4-26) > -------------------------------------- > Title : A Border Gateway Protocol 4 (BGP-4) > Publication Date : January 2006 > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > Category : DRAFT STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From stbryant@cisco.com Wed Oct 3 05:02:18 2012 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 3778A21F867F; Wed, 3 Oct 2012 05:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.602 X-Spam-Level: X-Spam-Status: No, score=-110.602 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnNT1BHxrDkJ; Wed, 3 Oct 2012 05:02:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF7821F86BD; Wed, 3 Oct 2012 05:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8422; q=dns/txt; s=iport; t=1349265734; x=1350475334; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=jJwartBzELIQh5YbLUSGFh+8WZLOrBcex398it0sl8Q=; b=O+ImDoufpdCY72e+7caIyePqipJ+YzSrj1yIW1wZv0YZbW/HGjOYFJQY KTUBodV+qNRzWf2vrJmVyEBhqml/vhs4W0ZteV9lEGClbe7Slmb4uzOJX ZhPbbhInG9A/ijKINOom0JdtCVZGpFQ8K9ENtD46eS9Uo0z+1MgUVPiTC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK8obFCQ/khL/2dsb2JhbABFvnOBCII5AQJjATwWGAMCAQIBSwEMAQcBAR6HY5gjg0oQgU6aUpFdA5VpjkKBBmOCboFi X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208,217";a="144714589" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Oct 2012 12:02:12 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q93C2BVV019192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 12:02:12 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q93C289I015649; Wed, 3 Oct 2012 13:02:09 +0100 (BST) Message-ID: <506C2940.2010507@cisco.com> Date: Wed, 03 Oct 2012 13:02:08 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "idr-chairs@tools.ietf.org" , idr mailing list , draft-ietf-idr-bgp-issues@tools.ietf.org Content-Type: multipart/alternative; boundary="------------050204090503030801000700" Cc: "iesg@ietf.org" Subject: [Idr] AD statement on draft-ietf-idr-bgp-issues X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:02:18 -0000 This is a multi-part message in MIME format. --------------050204090503030801000700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To the IDR WG, IDR WG Chairs and authors of draft-ietf-idr-bgp-issues: I have performed an Area Director review of draft-ietf-idr-bgp-issues (Issues in Revising BGP-4 (RFC1771 to RFC4271)), and it is my conclusion that, as submitted to me for AD review, this draft is not suitable for publication as an RFC in the IETF Series. Whilst I understand and support the goal of documenting the key design decisions that formed the basis of the BGP RFC4271, the method that the authors have chosen to present this information lacks the efficiency of presentation of information that I believe is required in the IETF RFC Series. The draft is a reproduction of detailed email exchanges that took place on the IDR list in the early part of the last decade, together with a running commentary and conclusion on each point. Within this 170 pages of text there is far too much cruft and irrelevant discussion for me to accept this publication request. As an aside I also have serious concerns at the extent of review that this document has received by the IDR WG. The only commenter during WG Last call states "... I did look at it when it first appeared, in 2005, and put it on the shelf for further study, where it has remained ever since." This in itself gives concerns regarding the method that the authors have chosen to present this information to the reader. I therefore think that IDR WG needs to find another way to record this information for posterity in a archival format. The IDR WG could proceed on a number of paths with this work. I suggest six ways forward here, but others may be also acceptable. 1) The IDR WG could heavily edit the draft so that it presents in a more conventional, significantly shorter format, the essential issues that were resolved and baked into RFC4271. I would sponsor the publication of a significantly reduced, well targeted, document. 2) The IDR WG could deconstruct the issues and record them in the IETF issue tracker software. This is a method that other WGs have used to address this problem. I accept that this was not possible when the draft was first written in 2003, and that this approach would be a great deal of work. We would have to verify the degree to which this approach matched the archival requirements of the IDR WG. 3) The IDR WG could make some minor modifications and publish this text on an IETF web page with a permanent URL. 3a) The IDR WG could write a short informational RFC that points to that web page so that whilst the text is not in the RFC series, it can be found from the RFC series of documents. 4) The IDR WG could request that the authors approach the Independent Stream RFC Editor, and ask that this draft be published as a RFC in the Independent Stream. Publication in the independent stream would require a conflict review, but if the consensus of the WG was to use this approach, I foresee no issue in that regard. If this approach is taken, I would suggest that the opinion of the IS Editor is sought, before making significant edits to the text of the draft. 5) The IDR WG Chairs could approach another member of the IESG and ask if they would be prepared to sponsor publication of this draft as an RFC. I would not block publication of the draft if it was sponsored by another Area Director. It is of course up to the IDR WG which path it is chosen to explore, but if I were going to progress this draft as a chair, I would probably start by exploring options (3+3a) and (4) in the list above, since this probably requires the least editing of the existing draft text. I am therefore returning this draft to the IDR working group, and await the decision of the IDR Chairs on how they wish to proceed. Regards Stewart --------------050204090503030801000700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 

To the IDR WG, IDR WG Chairs and authors of 
draft-ietf-idr-bgp-issues:

I have performed an Area Director review of 
draft-ietf-idr-bgp-issues (Issues in Revising BGP-4 
(RFC1771 to RFC4271)), and it is my conclusion that,
as submitted to me for AD review, this draft is not
suitable for publication as an RFC in the IETF 
Series.

Whilst I understand and support the goal of 
documenting the key design decisions that formed
the basis of the BGP RFC4271, the method
that the authors have chosen to present this 
information lacks the efficiency of presentation 
of information that I believe is required in the 
IETF RFC Series.

The draft is a reproduction of detailed email
exchanges that took place on the IDR list in the
early part of the last decade, together with a 
running commentary and conclusion on each
point. Within this 170 pages of text there
is far too much cruft and irrelevant discussion
for me to accept this publication request. 

As an aside I also have serious concerns at the 
extent of review that this document has received 
by the IDR WG. The only commenter during WG Last 
call states "... I did look at it when it first 
appeared, in 2005,  and put it on the shelf 
for further study, where it has remained 
ever since." This in itself gives concerns 
regarding the method that the authors have 
chosen to present this information to the reader.

I therefore think that IDR WG needs to find 
another way to record this information for 
posterity in a archival format.

The IDR WG could proceed on a number of paths with
this work. I suggest six ways forward here, but
others may be also acceptable.

1) The IDR WG could heavily edit the draft 
so that it presents in a more conventional, 
significantly shorter format, the essential 
issues that were resolved and baked into RFC4271.
I would sponsor the publication of a significantly
reduced, well targeted, document.

 2) The IDR WG could deconstruct the issues and 
record them in the IETF issue tracker software.
This is a method that other WGs have used to address
this problem. I accept that this was not possible
when the draft was first written in 2003, and that
this approach would be a great deal of work. We
would have to verify the degree to which this
approach matched the archival requirements of the 
IDR WG. 

 3) The IDR WG could make some minor modifications and
publish this text on an IETF web page with a 
permanent URL.

 3a) The IDR WG could write a short informational RFC that
points to that web page so that whilst the text is
not in the RFC series, it can be found from the RFC
series of documents.

4) The IDR WG could request that the authors approach 
the Independent Stream RFC Editor, and ask that 
this draft be published as a RFC in the Independent 
Stream. Publication in the independent stream would 
require a conflict review, but if the consensus of 
the WG was to use this approach, I foresee no 
issue in that regard. If this approach is taken,
I would suggest that the opinion of the IS Editor
is sought, before making significant edits to the 
text of the draft.

5) The IDR WG Chairs could approach another member 
of the IESG and ask if they would be prepared to 
sponsor publication of this draft as an RFC. I
would not block publication of the draft if it 
was sponsored by another Area Director.

It is of course up to the IDR WG which
path it is chosen to explore, but if I were
going to progress this draft as a chair, I would
probably start by exploring options (3+3a) and (4) 
in the list above, since this probably requires 
the least editing of the existing draft text.

I am therefore returning this draft to the IDR
working group, and await the decision of the 
IDR Chairs on how they wish to proceed.

Regards

Stewart
--------------050204090503030801000700-- From ietfc@btconnect.com Wed Oct 3 10:21:22 2012 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 511E021F84E2 for ; Wed, 3 Oct 2012 10:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnU+UvfiXKdl for ; Wed, 3 Oct 2012 10:21:21 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0273E21F8495 for ; Wed, 3 Oct 2012 10:21:19 -0700 (PDT) Received: from mail33-db3-R.bigfish.com (10.3.81.233) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 17:21:18 +0000 Received: from mail33-db3 (localhost [127.0.0.1]) by mail33-db3-R.bigfish.com (Postfix) with ESMTP id 1C9853402E3; Wed, 3 Oct 2012 17:21:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zz9371I542M1432I1418I4015Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh172cdfhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h304l1155h) Received: from mail33-db3 (localhost.localdomain [127.0.0.1]) by mail33-db3 (MessageSwitch) id 1349284876731759_9236; Wed, 3 Oct 2012 17:21:16 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.238]) by mail33-db3.bigfish.com (Postfix) with ESMTP id AD7C942010A; Wed, 3 Oct 2012 17:21:16 +0000 (UTC) Received: from AMSPRD0710HT002.eurprd07.prod.outlook.com (157.56.249.85) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 17:21:14 +0000 Received: from DBXPRD0310HT002.eurprd03.prod.outlook.com (157.56.252.133) by pod51017.outlook.com (10.255.160.165) with Microsoft SMTP Server (TLS) id 14.16.207.9; Wed, 3 Oct 2012 17:21:13 +0000 Message-ID: <000901cda18b$816c58e0$4001a8c0@gateway.2wire.net> From: t.petch To: Shashank Tyagi , , , , RFC Errata System References: <20120926090655.84AD3B1E002@rfc-editor.org> <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> <04d601cda0b7$d70b1720$4001a8c0@gateway.2wire.net> Date: Wed, 3 Oct 2012 18:21:14 +0100 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-Originating-IP: [157.56.252.133] X-FOPE-CRA-Verdict: 157.56.249.85$juniper.net%12218%4%btconnect.com%False%True%0$ X-OriginatorOrg: btconnect.com Cc: idr Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) 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, 03 Oct 2012 17:21:22 -0000 Shashank Whether or not the IETF accepts or rejects a proposed Erratum is up to the AD and he usually takes guidance from the relevant WG via the mailing list, which in this case is idr. Hence I am adding that as a Cc:. I remain confused. You say below [shtyagi] In my opinion the hold timer should not have any role unless the FSM thinks the BGP connection is active. The hold timer is only intended to check for activity in BGP session. My current (a bit rusty) thinking is that the HoldTimer is set when moving to OpenSent, OpenConfirm, Established states. Moving to OpenSent it is set to a large value (e.g. 4 minutes) and if it expires, we revert to Idle. If we lose the TCP connection, and this is something that the BGP engine cannot reliably know - that is the nature of TCP stacks - then we do not immediately give up but go back to Active, wait for the ConnectRetryTimer to expire, start a TCP connection, move to Connect and wait for success with TCP (again); we can then go back to OpenSent and restart the HoldTimer. But we can also stay in Active/Connect for ConnectRetryTimer and DelayOpenTimer one or more times and on TCP failure in Connect go back to Active. What I think that you are proposing is that this can go on for ever. What the current specification says is that if you have been going round this loop for a large amount of time without success, then it is time to give up. I think the current specification has it right. As you gather, my first reply misread the FSM thinking that a KEEPALIVE had been sent when it had not, but that was also irrelevant; the idea of the HoldTimer being there to clean things up has not changed. Tom Petch ----- Original Message ----- From: "Shashank Tyagi" To: "t.petch" ; ; ; ; "RFC Errata System" Sent: Tuesday, October 02, 2012 5:36 PM -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 9:35 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: idr@ietf.org ----- Original Message ----- From: "Shashank Tyagi" Sent: Tuesday, October 02, 2012 2:59 PM Hi Tom, Thanks for your reply. Yes it refers to OpenSent state sorry forgot to mention that. Few comments: -In OpenSent the KEEPALIVE has not been sent, only the Open message has been sent. So there would be no receipt of KEEPALIVE. Right, you are confusing me:-( Your proposed change was to set the HoldTimer to 0 when transitioning from OpenSent state to Active which made me think that a KEEPALIVE had been sent and the HoldTimer could be running in OpenSent and I thought I had found such a case in the FSM this morning. Looking again, I cannot find it so assume that no KEEPALIVE has been sent (I was probably reading OpenConfirm). [shtyagi] Probably OpenConfirm :) What then is your suggested change for the receipt of event 18 in OpenSent? To stop the HoldTimer if it is running? To ensure that the next use of the HoldTimer has a zero value and so is not started? Or what? [shtyagi] Yes to set the value to 0. Whenever the TCP is established again (in either ACTIVE state or CONNECT state) and OPEN Message sent out the Hold Timer Will get activated again. The FSM is intended to be robust in the event of all possibilities, including implementation errors, with the default being, when something completely impossible happens, go back to Idle state. In fact, there are an awful lot of corner cases arising out of such as connection collisions, of data being buffered in the TCP stack when BGP thinks there is no connection, TCP connection dropping and either noone noticing or restarting etc so even a perfect implementation can do some strange things. If, thus, the HoldTimer expires in Active state, the only thing to do IMHO is to revert to Idle (and call your software supplier if you are sure it cannot happen:-) - as I said before, the expectation is that the ConnectRetryTimer will expire first taking it back to OpenSent. [shtyagi] In my opinion the hold timer should not have any role unless the FSM thinks the BGP connection is active. The hold timer is only intended to check for activity in BGP session. All the corner cases that you have mentioned above are already being handled in the FSM. BGP packets in queue after TCP failure if received in ACTIVE state will be discarded with state changed to IDLE. Am suggesting to only turn of the Hold Timer only after we decide the TCP has failed and we are closing the BGP connection. There is an additional problem in case the value is not reset. Even assuming the connection retry is 90s and HoldTimer is 4 mins, when ConnectRetry timer expires in ACTIVE state we don't reset the HoldTimer and move to CONNECT state. Ideally if peer is not accepting TCP connections we should remain stuck in CONNECT state with ConnectRetry counter restarting. But in above path with HoldTimer in some value we would after 1-2 tries change state back to IDLE state which should not be the case. Thanks, Shashank Tom Petch -Also when moving from OPENSENT to ACTIVE in case of TCP failure the rfc says to close the BGP connection. Why should the HoldTimer be running without a BGP connection? Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 7:12 PM To: yakov@juniper.net; tony.li@tony.li; skh@nexthop.com; stbryant@cisco.com; adrian@olddog.co.uk; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: Shashank Tyagi; rfc-editor@rfc-editor.org; idr@ietf.org Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) >From the Original Text, I infer that this refers to OpenSent, when event 18 occurs. The Notes say "HoldTimer should only be used to control time in between BGP packets. " This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as well as an OPEN) so the timer should be running. "Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state." Well, it will lead to Active state (p.59) - that is what the text says - and event 10, HoldTimer expires, will then take you to Idle state (p.63). The expectation is that the HoldTimer has been set to a large value, 4 minutes, which is much greater than the ConnectRetryTimer (90s) and it is the expiry of the latter that should take you out of Active state to Connect and thence to OpenSent when the HoldTimer will be restarted. Note that the receipt of a KEEPALIVE (event 26) also takes you from Active to Idle - I think that the two cases are similar, that the BGP connection did not reach second base. You are in trouble either way and back to Idle is the safe thing to do. Of course, if you ignore that advice to set the HoldTimer to a large value - you have yet to receive an OPEN and so do not know what value will be acceptable to the peer - and set it instead to 3s, then yes, you will get back to Idle more often than is desirable. Nowadays, there is a greater wish to keep BGP connections up, compared to when we wrote RFC4271, but I think that, in this case, there is nothing worth keeping up and going back to Idle is the right thing to do. (I am not sure what the best distribution for this is so I have used 'Reply All' but expect that that should be trimmed soon). Tom Petch ----- Original Message ----- From: "RFC Errata System" To: ; ; ; ; ; ; Cc: ; ; Sent: Wednesday, September 26, 2012 10:06 AM Subject: [Idr] [Technical Errata Reported] RFC4271 (3366) > > The following errata report has been submitted for RFC4271, "A Border > Gateway Protocol 4 (BGP-4)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3366 > > -------------------------------------- > Type: Technical > Reported by: Shashank Tyagi > > Section: 8.2.2 > > Original Text > ------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Corrected Text > -------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - sets the HoldTimer to 0, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Notes > ----- > HoldTimer should only be used to control time in between BGP packets. > Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state. > > 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. > > -------------------------------------- > RFC4271 (draft-ietf-idr-bgp4-26) > -------------------------------------- > Title : A Border Gateway Protocol 4 (BGP-4) > Publication Date : January 2006 > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > Category : DRAFT STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From Shashank.Tyagi@microsoft.com Wed Oct 3 11:16:54 2012 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 3366421F859F for ; Wed, 3 Oct 2012 11:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KL0EsGUCsRN3 for ; Wed, 3 Oct 2012 11:16:53 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id C560221F85C0 for ; Wed, 3 Oct 2012 11:16:52 -0700 (PDT) Received: from mail204-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 18:16:52 +0000 Received: from mail204-ch1 (localhost [127.0.0.1]) by mail204-ch1-R.bigfish.com (Postfix) with ESMTP id 3427A20168; Wed, 3 Oct 2012 18:16:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz9371I542M1432I1418I4015Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh172cdfhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: pass (mail204-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shashank.Tyagi@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail204-ch1 (localhost.localdomain [127.0.0.1]) by mail204-ch1 (MessageSwitch) id 1349288209243891_15347; Wed, 3 Oct 2012 18:16:49 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail204-ch1.bigfish.com (Postfix) with ESMTP id 3789040004E; Wed, 3 Oct 2012 18:16:49 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 18:16:48 +0000 Received: from SINEX14HUBC402.southpacific.corp.microsoft.com (157.60.220.216) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 3 Oct 2012 18:16:32 +0000 Received: from SINEX14MBXC401.southpacific.corp.microsoft.com ([169.254.1.140]) by SINEX14HUBC402.southpacific.corp.microsoft.com ([157.60.220.216]) with mapi id 14.02.0309.003; Wed, 3 Oct 2012 18:16:19 +0000 From: Shashank Tyagi To: t.petch , "stbryant@cisco.com" , "shares@ndzh.com" , "jgs@juniper.net" , RFC Errata System Thread-Topic: [Idr] [Technical Errata Reported] RFC4271 (3366) Thread-Index: AQHNm8bsE8GH85SgyUCDhjNPddrFsJemEEpsgAACBJCAACXUMYAAAuuggAGkayaAAAxsYA== Date: Wed, 3 Oct 2012 18:16:18 +0000 Message-ID: References: <20120926090655.84AD3B1E002@rfc-editor.org> <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> <04d601cda0b7$d70b1720$4001a8c0@gateway.2wire.net> <000901cda18b$816c58e0$4001a8c0@gateway.2wire.net> In-Reply-To: <000901cda18b$816c58e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 131.107.125.8$juniper.net%12218%4%microsoft.com%False%True%0$btconnect.com%0%1%microsoft.com%False%False%0$ X-OriginatorOrg: microsoft.com Cc: idr Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) 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, 03 Oct 2012 18:16:54 -0000 Hi Tom, My message wont reach idr list without approval so please for= ward (or reply back) if necessary. Keeping them in cc.=20 Few quick notes: -Completely agree about the HoldTimer point.=20 -Whether we lose the TCP or not we rely on the stack for that. If stack ret= urns the failure then we take it as TCP fail. Even a TCP FIN is taken as a = failure. Also while moving to ACTIVE state we close the BGP connection and = wait in ACTIVE for sometime (ConnectRetryTimer) and then try to establish t= he connection again. If it does go through then HoldTimer is reset. Agree a= bout your interpretation for this point as well.=20 -Even in the current specification we can go around this loop infinitely as= long as ConnectRetryTimer expires before the HoldTimer as we reset it each= time before moving on to OpenSent. So I disagree with using the HoldTimer = for stopping infinite loop.=20 -To add to above for this purpose of stopping infinite loops or some restri= ctions the implementation could use the CONNECTRETRYCOUNTER which is meant = for this.=20 -Even without the above TCPFail case when trying to connect to peer (who ma= y be inactive or unreachable) we are in infinite loop of CONNECT and ACTIVE= . The only place we go back to IDLE is two consecutive TCP Fail one of whic= h must occur in ACTIVE state. Again to stop infinite loop if interested the= implementation should use CONNECTRETRYCOUNTER. -KeepAlive is irrelevant so we can drop it from discussions.=20 Thanks, Shashank=20 -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com]=20 Sent: Wednesday, October 3, 2012 10:51 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; R= FC Errata System Cc: idr Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) Shashank Whether or not the IETF accepts or rejects a proposed Erratum is up to the = AD and he usually takes guidance from the relevant WG via the mailing list,= which in this case is idr. Hence I am adding that as a Cc:. I remain confused. You say below [shtyagi] In my opinion the hold timer should not have any role unless the FSM thinks= the BGP connection is active. The hold timer is only intended to check for= activity in BGP session. My current (a bit rusty) thinking is that the HoldTimer is set when moving = to OpenSent, OpenConfirm, Established states. Moving to OpenSent it is set= to a large value (e.g. 4 minutes) and if it expires, we revert to Idle. I= f we lose the TCP connection, and this is something that the BGP engine can= not reliably know - that is the nature of TCP stacks - then we do not immed= iately give up but go back to Active, wait for the ConnectRetryTimer to exp= ire, start a TCP connection, move to Connect and wait for success with TCP = (again); we can then go back to OpenSent and restart the HoldTimer. But we can also stay in Active/Connect for ConnectRetryTimer and DelayOpenT= imer one or more times and on TCP failure in Connect go back to Active. What I think that you are proposing is that this can go on for ever. What the current specification says is that if you have been going round th= is loop for a large amount of time without success, then it is time to give= up. I think the current specification has it right. As you gather, my first reply misread the FSM thinking that a KEEPALIVE had= been sent when it had not, but that was also irrelevant; the idea of the H= oldTimer being there to clean things up has not changed. Tom Petch ----- Original Message ----- From: "Shashank Tyagi" To: "t.petch" ; ; ; ; "RFC Errata System" Sent: Tuesday, October 02, 2012 5:36 PM -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 9:35 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; R= FC Errata System Cc: idr@ietf.org ----- Original Message ----- From: "Shashank Tyagi" Sent: Tuesday, October 02, 2012 2:59 PM Hi Tom, Thanks for your reply. Yes it refers to OpenSent state sorry = forgot to mention that. Few comments: -In OpenSent the KEEPALIVE has not been sent, only the Open message has bee= n sent. So there would be no receipt of KEEPALIVE. Right, you are confusing me:-( Your proposed change was to set the HoldTimer to 0 when transitioning from = OpenSent state to Active which made me think that a KEEPALIVE had been sent= and the HoldTimer could be running in OpenSent and I thought I had found s= uch a case in the FSM this morning. Looking again, I cannot find it so ass= ume that no KEEPALIVE has been sent (I was probably reading OpenConfirm). [shtyagi] Probably OpenConfirm :) What then is your suggested change for the receipt of event 18 in OpenSent? To stop the HoldTimer if it is running? To ensure that the next use of the HoldTimer has a zero value and so is not= started? Or what? [shtyagi] Yes to set the value to 0. Whenever the TCP is established again (in either= ACTIVE state or CONNECT state) and OPEN Message sent out the Hold Timer Wi= ll get activated again. The FSM is intended to be robust in the event of all possibilities, includi= ng implementation errors, with the default being, when something completely= impossible happens, go back to Idle state. In fact, there are an awful lot of corner cases arising out of such as conn= ection collisions, of data being buffered in the TCP stack when BGP thinks = there is no connection, TCP connection dropping and either noone noticing o= r restarting etc so even a perfect implementation can do some strange thing= s. If, thus, the HoldTimer expires in Active state, the only thing to do I= MHO is to revert to Idle (and call your software supplier if you are sure i= t cannot happen:-) - as I said before, the expectation is that the ConnectR= etryTimer will expire first taking it back to OpenSent. [shtyagi] In my opinion the hold timer should not have any role unless the FSM thinks= the BGP connection is active. The hold timer is only intended to check for= activity in BGP session. All the corner cases that you have mentioned above are already being handle= d in the FSM. BGP packets in queue after TCP failure if received in ACTIVE state will be = discarded with state changed to IDLE. Am suggesting to only turn of the Hold Timer only after we decide the TCP h= as failed and we are closing the BGP connection. There is an additional problem in case the value is not reset. Even assumin= g the connection retry is 90s and HoldTimer is 4 mins, when ConnectRetry ti= mer expires in ACTIVE state we don't reset the HoldTimer and move to CONNEC= T state. Ideally if peer is not accepting TCP connections we should remain stuck in = CONNECT state with ConnectRetry counter restarting. But in above path with HoldTimer in some value we would after 1-2 tries cha= nge state back to IDLE state which should not be the case. Thanks, Shashank Tom Petch -Also when moving from OPENSENT to ACTIVE in case of TCP failure the rfc sa= ys to close the BGP connection. Why should the HoldTimer be running without= a BGP connection? Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 7:12 PM To: yakov@juniper.net; tony.li@tony.li; skh@nexthop.com; stbryant@cisco.com= ; adrian@olddog.co.uk; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: Shashank Tyagi; rfc-editor@rfc-editor.org; idr@ietf.org Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) >From the Original Text, I infer that this refers to OpenSent, when event 18 occurs. The Notes say "HoldTimer should only be used to control time in between BGP packets. " This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as we= ll as an OPEN) so the timer should be running. "Also in this case it can lead to case in ACTIVE state where HoldTimer expi= res before the ConnectRetryTimer leading to IDLE state." Well, it will lead to Active state (p.59) - that is what the text says - an= d event 10, HoldTimer expires, will then take you to Idle state (p.63). The expectation is that the HoldTimer has been set to a large value, 4 minu= tes, which is much greater than the ConnectRetryTimer (90s) and it is the e= xpiry of the latter that should take you out of Active state to Connect and= thence to OpenSent when the HoldTimer will be restarted. Note that the receipt of a KEEPALIVE (event 26) also takes you from Active = to Idle - I think that the two cases are similar, that the BGP connection d= id not reach second base. You are in trouble either way and back to Idle i= s the safe thing to do. Of course, if you ignore that advice to set the HoldTimer to a large value = - you have yet to receive an OPEN and so do not know what value will be acc= eptable to the peer - and set it instead to 3s, then yes, you will get back= to Idle more often than is desirable. Nowadays, there is a greater wish to keep BGP connections up, compared to w= hen we wrote RFC4271, but I think that, in this case, there is nothing wort= h keeping up and going back to Idle is the right thing to do. (I am not sure what the best distribution for this is so I have used 'Reply= All' but expect that that should be trimmed soon). Tom Petch ----- Original Message ----- From: "RFC Errata System" To: ; ; ; ; ; ; Cc: ; ; Sent: Wednesday, September 26, 2012 10:06 AM Subject: [Idr] [Technical Errata Reported] RFC4271 (3366) > > The following errata report has been submitted for RFC4271, "A Border=20 > Gateway Protocol 4 (BGP-4)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4271&eid=3D3366 > > -------------------------------------- > Type: Technical > Reported by: Shashank Tyagi > > Section: 8.2.2 > > Original Text > ------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Corrected Text > -------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - sets the HoldTimer to 0, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Notes > ----- > HoldTimer should only be used to control time in between BGP packets. > Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > 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=20 > change the status and edit the report, if necessary. > > -------------------------------------- > RFC4271 (draft-ietf-idr-bgp4-26) > -------------------------------------- > Title : A Border Gateway Protocol 4 (BGP-4) > Publication Date : January 2006 > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > Category : DRAFT STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From ietfc@btconnect.com Thu Oct 4 04:11:08 2012 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 E73CF21F865B for ; Thu, 4 Oct 2012 04:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfR0ScrYROIO for ; Thu, 4 Oct 2012 04:11:07 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id DA63E21F8653 for ; Thu, 4 Oct 2012 04:10:59 -0700 (PDT) Received: from mail10-am1-R.bigfish.com (10.3.201.245) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 11:10:59 +0000 Received: from mail10-am1 (localhost [127.0.0.1]) by mail10-am1-R.bigfish.com (Postfix) with ESMTP id 150FD22017A; Thu, 4 Oct 2012 11:10:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz9371I1102I542M1432I1418I4015Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh172cdfhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h304l1155h) Received: from mail10-am1 (localhost.localdomain [127.0.0.1]) by mail10-am1 (MessageSwitch) id 1349349056173269_18634; Thu, 4 Oct 2012 11:10:56 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.252]) by mail10-am1.bigfish.com (Postfix) with ESMTP id 25E361C00B1; Thu, 4 Oct 2012 11:10:56 +0000 (UTC) Received: from DB3PRD0710HT005.eurprd07.prod.outlook.com (157.56.253.85) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 4 Oct 2012 11:10:53 +0000 Received: from DBXPRD0310HT005.eurprd03.prod.outlook.com (157.56.252.133) by pod51017.outlook.com (10.255.75.40) with Microsoft SMTP Server (TLS) id 14.16.190.9; Thu, 4 Oct 2012 11:10:47 +0000 Message-ID: <023f01cda220$ebd265e0$4001a8c0@gateway.2wire.net> From: t.petch To: Shashank Tyagi , , , , RFC Errata System References: <20120926090655.84AD3B1E002@rfc-editor.org> <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> <04d601cda0b7$d70b1720$4001a8c0@gateway.2wire.net> <000901cda18b$816c58e0$4001a8c0@gateway.2wire.net> Date: Thu, 4 Oct 2012 12:04:10 +0100 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-Originating-IP: [157.56.252.133] X-FOPE-CRA-Verdict: 157.56.253.85$juniper.net%12218%4%btconnect.com%False%True%0$ X-OriginatorOrg: btconnect.com Cc: idr Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) 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, 04 Oct 2012 11:11:09 -0000 ---- Original Message ----- From: "Shashank Tyagi" To: "t.petch" ; ; ; ; "RFC Errata System" Cc: "idr" Sent: Wednesday, October 03, 2012 7:16 PM Hi Tom, My message wont reach idr list without approval so please forward (or reply back) if necessary. Keeping them in cc. Few quick notes: -Completely agree about the HoldTimer point. -Whether we lose the TCP or not we rely on the stack for that. If stack returns the failure then we take it as TCP fail. Even a TCP FIN is taken as a failure. Also while moving to ACTIVE state we close the BGP connection and wait in ACTIVE for sometime (ConnectRetryTimer) and then try to establish the connection again. If it does go through then HoldTimer is reset. Agree about your interpretation for this point as well. -Even in the current specification we can go around this loop infinitely as long as ConnectRetryTimer expires before the HoldTimer as we reset it each time before moving on to OpenSent. So I disagree with using the HoldTimer for stopping infinite loop. -To add to above for this purpose of stopping infinite loops or some restrictions the implementation could use the CONNECTRETRYCOUNTER which is meant for this. -Even without the above TCPFail case when trying to connect to peer (who may be inactive or unreachable) we are in infinite loop of CONNECT and ACTIVE. The only place we go back to IDLE is two consecutive TCP Fail one of which must occur in ACTIVE state. Again to stop infinite loop if interested the implementation should use CONNECTRETRYCOUNTER. -KeepAlive is irrelevant so we can drop it from discussions. Shashank You say that we are dependent on the stack for knowing whether or not TCP is up, but in the general case, this is obviously untrue, else we would never have KEEPALIVE - TCP often does not notice rock solid Layer 2 failures and whilst a false report of TCP failing is rare, I expect it happens as well. The application must take care of itself regardless of what TCP says. You say that ConnectRetryCounter is intended to stop loops but that is not what the FSM says - I see no event to the effect that the ConnectRetryCounter has exceeded some value and it is time to drop the session; rather, the FSM depends on timers and their expiry. Cycling between Active and Connect never having got further I am comfortable with; we may have to wait a long time for the peer to become available and we have yet to reach first base. Cycling between Active and Connect having sent an OPEN, which probably arrived which could mean the peer thinks we have received an OPEN and are in OpenConfirm I am not comfortable with - we SHOULD NOT stay there for long and HoldTimer expiry is the way out. I think the current specification has it right:-) Tom Petch Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Wednesday, October 3, 2012 10:51 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: idr Shashank I remain confused. You say below [shtyagi] In my opinion the hold timer should not have any role unless the FSM thinks the BGP connection is active. The hold timer is only intended to check for activity in BGP session. My current (a bit rusty) thinking is that the HoldTimer is set when moving to OpenSent, OpenConfirm, Established states. Moving to OpenSent it is set to a large value (e.g. 4 minutes) and if it expires, we revert to Idle. If we lose the TCP connection, and this is something that the BGP engine cannot reliably know - that is the nature of TCP stacks - then we do not immediately give up but go back to Active, wait for the ConnectRetryTimer to expire, start a TCP connection, move to Connect and wait for success with TCP (again); we can then go back to OpenSent and restart the HoldTimer. But we can also stay in Active/Connect for ConnectRetryTimer and DelayOpenTimer one or more times and on TCP failure in Connect go back to Active. What I think that you are proposing is that this can go on for ever. What the current specification says is that if you have been going round this loop for a large amount of time without success, then it is time to give up. I think the current specification has it right. As you gather, my first reply misread the FSM thinking that a KEEPALIVE had been sent when it had not, but that was also irrelevant; the idea of the HoldTimer being there to clean things up has not changed. Tom Petch ----- Original Message ----- From: "Shashank Tyagi" To: "t.petch" ; ; ; ; "RFC Errata System" Sent: Tuesday, October 02, 2012 5:36 PM -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 9:35 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: idr@ietf.org ----- Original Message ----- From: "Shashank Tyagi" Sent: Tuesday, October 02, 2012 2:59 PM Hi Tom, Thanks for your reply. Yes it refers to OpenSent state sorry forgot to mention that. Few comments: -In OpenSent the KEEPALIVE has not been sent, only the Open message has been sent. So there would be no receipt of KEEPALIVE. Right, you are confusing me:-( Your proposed change was to set the HoldTimer to 0 when transitioning from OpenSent state to Active which made me think that a KEEPALIVE had been sent and the HoldTimer could be running in OpenSent and I thought I had found such a case in the FSM this morning. Looking again, I cannot find it so assume that no KEEPALIVE has been sent (I was probably reading OpenConfirm). [shtyagi] Probably OpenConfirm :) What then is your suggested change for the receipt of event 18 in OpenSent? To stop the HoldTimer if it is running? To ensure that the next use of the HoldTimer has a zero value and so is not started? Or what? [shtyagi] Yes to set the value to 0. Whenever the TCP is established again (in either ACTIVE state or CONNECT state) and OPEN Message sent out the Hold Timer Will get activated again. The FSM is intended to be robust in the event of all possibilities, including implementation errors, with the default being, when something completely impossible happens, go back to Idle state. In fact, there are an awful lot of corner cases arising out of such as connection collisions, of data being buffered in the TCP stack when BGP thinks there is no connection, TCP connection dropping and either noone noticing or restarting etc so even a perfect implementation can do some strange things. If, thus, the HoldTimer expires in Active state, the only thing to do IMHO is to revert to Idle (and call your software supplier if you are sure it cannot happen:-) - as I said before, the expectation is that the ConnectRetryTimer will expire first taking it back to OpenSent. [shtyagi] In my opinion the hold timer should not have any role unless the FSM thinks the BGP connection is active. The hold timer is only intended to check for activity in BGP session. All the corner cases that you have mentioned above are already being handled in the FSM. BGP packets in queue after TCP failure if received in ACTIVE state will be discarded with state changed to IDLE. Am suggesting to only turn of the Hold Timer only after we decide the TCP has failed and we are closing the BGP connection. There is an additional problem in case the value is not reset. Even assuming the connection retry is 90s and HoldTimer is 4 mins, when ConnectRetry timer expires in ACTIVE state we don't reset the HoldTimer and move to CONNECT state. Ideally if peer is not accepting TCP connections we should remain stuck in CONNECT state with ConnectRetry counter restarting. But in above path with HoldTimer in some value we would after 1-2 tries change state back to IDLE state which should not be the case. Thanks, Shashank Tom Petch -Also when moving from OPENSENT to ACTIVE in case of TCP failure the rfc says to close the BGP connection. Why should the HoldTimer be running without a BGP connection? Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 7:12 PM To: yakov@juniper.net; tony.li@tony.li; skh@nexthop.com; stbryant@cisco.com; adrian@olddog.co.uk; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: Shashank Tyagi; rfc-editor@rfc-editor.org; idr@ietf.org Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) >From the Original Text, I infer that this refers to OpenSent, when event 18 occurs. The Notes say "HoldTimer should only be used to control time in between BGP packets. " This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as well as an OPEN) so the timer should be running. "Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state." Well, it will lead to Active state (p.59) - that is what the text says - and event 10, HoldTimer expires, will then take you to Idle state (p.63). The expectation is that the HoldTimer has been set to a large value, 4 minutes, which is much greater than the ConnectRetryTimer (90s) and it is the expiry of the latter that should take you out of Active state to Connect and thence to OpenSent when the HoldTimer will be restarted. Note that the receipt of a KEEPALIVE (event 26) also takes you from Active to Idle - I think that the two cases are similar, that the BGP connection did not reach second base. You are in trouble either way and back to Idle is the safe thing to do. Of course, if you ignore that advice to set the HoldTimer to a large value - you have yet to receive an OPEN and so do not know what value will be acceptable to the peer - and set it instead to 3s, then yes, you will get back to Idle more often than is desirable. Nowadays, there is a greater wish to keep BGP connections up, compared to when we wrote RFC4271, but I think that, in this case, there is nothing worth keeping up and going back to Idle is the right thing to do. (I am not sure what the best distribution for this is so I have used 'Reply All' but expect that that should be trimmed soon). Tom Petch ----- Original Message ----- From: "RFC Errata System" To: ; ; ; ; ; ; Cc: ; ; Sent: Wednesday, September 26, 2012 10:06 AM Subject: [Idr] [Technical Errata Reported] RFC4271 (3366) > > The following errata report has been submitted for RFC4271, "A Border > Gateway Protocol 4 (BGP-4)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3366 > > -------------------------------------- > Type: Technical > Reported by: Shashank Tyagi > > Section: 8.2.2 > > Original Text > ------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Corrected Text > -------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - sets the HoldTimer to 0, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Notes > ----- > HoldTimer should only be used to control time in between BGP packets. > Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state. > > 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. > > -------------------------------------- > RFC4271 (draft-ietf-idr-bgp4-26) > -------------------------------------- > Title : A Border Gateway Protocol 4 (BGP-4) > Publication Date : January 2006 > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > Category : DRAFT STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From Shashank.Tyagi@microsoft.com Thu Oct 4 09:35:51 2012 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 BDDA221F869C for ; Thu, 4 Oct 2012 09:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6exCZ23GPCL for ; Thu, 4 Oct 2012 09:35:50 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 170C821F868A for ; Thu, 4 Oct 2012 09:35:50 -0700 (PDT) Received: from mail269-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 16:35:46 +0000 Received: from mail269-va3 (localhost [127.0.0.1]) by mail269-va3-R.bigfish.com (Postfix) with ESMTP id 1B80F16000F5; Thu, 4 Oct 2012 16:35:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(zz9371I1102I542M1432I1418I4015Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh172cdfhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: pass (mail269-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shashank.Tyagi@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail269-va3 (localhost.localdomain [127.0.0.1]) by mail269-va3 (MessageSwitch) id 1349368544564910_27505; Thu, 4 Oct 2012 16:35:44 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.243]) by mail269-va3.bigfish.com (Postfix) with ESMTP id 8679324004E; Thu, 4 Oct 2012 16:35:44 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 4 Oct 2012 16:35:41 +0000 Received: from SINEX14HUBC401.southpacific.corp.microsoft.com (157.60.220.215) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 4 Oct 2012 16:35:40 +0000 Received: from SINEX14MBXC401.southpacific.corp.microsoft.com ([169.254.1.140]) by SINEX14HUBC401.southpacific.corp.microsoft.com ([157.60.220.215]) with mapi id 14.02.0309.003; Thu, 4 Oct 2012 16:35:10 +0000 From: Shashank Tyagi To: t.petch , "stbryant@cisco.com" , "shares@ndzh.com" , "jgs@juniper.net" , RFC Errata System Thread-Topic: [Idr] [Technical Errata Reported] RFC4271 (3366) Thread-Index: AQHNm8bsE8GH85SgyUCDhjNPddrFsJemEEpsgAACBJCAACXUMYAAAuuggAGkayaAAAxsYIABHm9cgAApRaA= Date: Thu, 4 Oct 2012 16:35:09 +0000 Message-ID: References: <20120926090655.84AD3B1E002@rfc-editor.org> <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> <04d601cda0b7$d70b1720$4001a8c0@gateway.2wire.net> <000901cda18b$816c58e0$4001a8c0@gateway.2wire.net> <023f01cda220$ebd265e0$4001a8c0@gateway.2wire.net> In-Reply-To: <023f01cda220$ebd265e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 131.107.125.8$juniper.net%12218%4%microsoft.com%False%True%0$btconnect.com%0%1%microsoft.com%False%False%0$ X-OriginatorOrg: microsoft.com Cc: idr Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) 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, 04 Oct 2012 16:35:51 -0000 Hi Tom, Few comments inline. And I still think that for all scenari= os that you've suggested so far HOLDTIMER is not the right approach and oth= er approaches already exist :)=20 Also I feel we can converge on this faster if we can have a quick chat than= on mails. If you still strongly feel that having HOLDTIMER running in ACTI= VE or CONNECT state without any bgp connection is important and correct and= if others also feel the same then please send me your final comments for r= ejecting the errata.=20 Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com]=20 Sent: Thursday, October 4, 2012 4:34 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; R= FC Errata System Cc: idr Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) ---- Original Message ----- From: "Shashank Tyagi" To: "t.petch" ; ; ; ; "RFC Errata System" Cc: "idr" Sent: Wednesday, October 03, 2012 7:16 PM Hi Tom, My message wont reach idr list without approval so please for= ward (or reply back) if necessary. Keeping them in cc. Few quick notes: -Completely agree about the HoldTimer point. -Whether we lose the TCP or not we rely on the stack for that. If stack ret= urns the failure then we take it as TCP fail. Even a TCP FIN is taken as a = failure. Also while moving to ACTIVE state we close the BGP connection and = wait in ACTIVE for sometime (ConnectRetryTimer) and then try to establish t= he connection again. If it does go through then HoldTimer is reset. Agree a= bout your interpretation for this point as well. -Even in the current specification we can go around this loop infinitely as= long as ConnectRetryTimer expires before the HoldTimer as we reset it each= time before moving on to OpenSent. So I disagree with using the HoldTimer = for stopping infinite loop. -To add to above for this purpose of stopping infinite loops or some restri= ctions the implementation could use the CONNECTRETRYCOUNTER which is meant = for this. -Even without the above TCPFail case when trying to connect to peer (who ma= y be inactive or unreachable) we are in infinite loop of CONNECT and ACTIVE= . The only place we go back to IDLE is two consecutive TCP Fail one of whic= h must occur in ACTIVE state. Again to stop infinite loop if interested the= implementation should use CONNECTRETRYCOUNTER. -KeepAlive is irrelevant so we can drop it from discussions. Shashank You say that we are dependent on the stack for knowing whether or not TCP i= s up, but in the general case, this is obviously untrue, else we would neve= r have KEEPALIVE - TCP often does not notice rock solid Layer 2 failures and whilst a false report of TCP failing is rare, I expect it ha= ppens as well. The application must take care of itself regardless of what= TCP says. Whatever be the scenario this can be out of scope here. Also the implementa= tion of KEEPALIVE is also required in valid cases where the BGP fails but n= ot the underlying TCP. But the cases youre saying are possible as well but = in that case where TCP fails and stack fails to inform us about it we remai= n in the OPENSENT state where HOLDTIMER is perfectly valid and will take ca= re of any such failure/scenario. You say that ConnectRetryCounter is intended to stop loops but that is not = what the FSM says - I see no event to the effect that the ConnectRetryCount= er has exceeded some value and it is time to drop the session; rather, the = FSM depends on timers and their expiry. No it doesn't but neither does the RFC give any other purpose for maintaini= ng the counter. As far as my understanding goes it CAN (if implementation w= ants to stop loops) be used to stop loops after a time but if you have a be= tter understanding or use for it then please share.=20 Cycling between Active and Connect never having got further I am comfortabl= e with; we may have to wait a long time for the peer to become available an= d we have yet to reach first base. Cycling between Active and Connect having sent an OPEN, which probably arri= ved which could mean the peer thinks we have received an OPEN and are in Op= enConfirm I am not comfortable with - we SHOULD NOT stay there for long and= HoldTimer expiry is the way out. While what youre saying is correct it is more for finding out some purpose = of the HoldTimer in this state. Few points about this: -The scenario you described says that the PEER-FSM might have reached OpenS= ent/Confirm state and thinks we are also in different state (than ACTIVE). = Then this will be handled by the HoldTimer running on the PEER if the TCP f= ail was not real (or not communicated to the peer). FSM on one side should = not be having anything which detects problems in PEER-FSM.=20 -If we don't want to retry connecting to the peer in case of TCP failure fr= om OPENSENT state then why on Event 18 we don't just go to IDLE like we go = from OPENCONFIRM or ESTABLISHED? Going back to ACTIVE means that we are int= erested in trying to connect to the peer again. If the TCP is really flaky = or due to some error the TCP failure occurs twice simultaneously then only = should we be going to IDLE state from ACTIVE state and not based on value o= f HOLDTIMER.=20 I think the current specification has it right:-) Tom Petch Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Wednesday, October 3, 2012 10:51 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; R= FC Errata System Cc: idr Shashank I remain confused. You say below [shtyagi] In my opinion the hold timer should not have any role unless the FSM thinks= the BGP connection is active. The hold timer is only intended to check for= activity in BGP session. My current (a bit rusty) thinking is that the HoldTimer is set when moving = to OpenSent, OpenConfirm, Established states. Moving to OpenSent it is set= to a large value (e.g. 4 minutes) and if it expires, we revert to Idle. I= f we lose the TCP connection, and this is something that the BGP engine can= not reliably know - that is the nature of TCP stacks - then we do not immed= iately give up but go back to Active, wait for the ConnectRetryTimer to exp= ire, start a TCP connection, move to Connect and wait for success with TCP = (again); we can then go back to OpenSent and restart the HoldTimer. But we can also stay in Active/Connect for ConnectRetryTimer and DelayOpenT= imer one or more times and on TCP failure in Connect go back to Active. What I think that you are proposing is that this can go on for ever. What the current specification says is that if you have been going round th= is loop for a large amount of time without success, then it is time to give= up. I think the current specification has it right. As you gather, my first reply misread the FSM thinking that a KEEPALIVE had= been sent when it had not, but that was also irrelevant; the idea of the H= oldTimer being there to clean things up has not changed. Tom Petch ----- Original Message ----- From: "Shashank Tyagi" To: "t.petch" ; ; ; ; "RFC Errata System" Sent: Tuesday, October 02, 2012 5:36 PM -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 9:35 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; R= FC Errata System Cc: idr@ietf.org ----- Original Message ----- From: "Shashank Tyagi" Sent: Tuesday, October 02, 2012 2:59 PM Hi Tom, Thanks for your reply. Yes it refers to OpenSent state sorry = forgot to mention that. Few comments: -In OpenSent the KEEPALIVE has not been sent, only the Open message has bee= n sent. So there would be no receipt of KEEPALIVE. Right, you are confusing me:-( Your proposed change was to set the HoldTimer to 0 when transitioning from = OpenSent state to Active which made me think that a KEEPALIVE had been sent= and the HoldTimer could be running in OpenSent and I thought I had found s= uch a case in the FSM this morning. Looking again, I cannot find it so ass= ume that no KEEPALIVE has been sent (I was probably reading OpenConfirm). [shtyagi] Probably OpenConfirm :) What then is your suggested change for the receipt of event 18 in OpenSent? To stop the HoldTimer if it is running? To ensure that the next use of the HoldTimer has a zero value and so is not= started? Or what? [shtyagi] Yes to set the value to 0. Whenever the TCP is established again (in either= ACTIVE state or CONNECT state) and OPEN Message sent out the Hold Timer Wi= ll get activated again. The FSM is intended to be robust in the event of all possibilities, includi= ng implementation errors, with the default being, when something completely= impossible happens, go back to Idle state. In fact, there are an awful lot of corner cases arising out of such as conn= ection collisions, of data being buffered in the TCP stack when BGP thinks = there is no connection, TCP connection dropping and either noone noticing o= r restarting etc so even a perfect implementation can do some strange thing= s. If, thus, the HoldTimer expires in Active state, the only thing to do I= MHO is to revert to Idle (and call your software supplier if you are sure i= t cannot happen:-) - as I said before, the expectation is that the ConnectR= etryTimer will expire first taking it back to OpenSent. [shtyagi] In my opinion the hold timer should not have any role unless the FSM thinks= the BGP connection is active. The hold timer is only intended to check for= activity in BGP session. All the corner cases that you have mentioned above are already being handle= d in the FSM. BGP packets in queue after TCP failure if received in ACTIVE state will be = discarded with state changed to IDLE. Am suggesting to only turn of the Hold Timer only after we decide the TCP h= as failed and we are closing the BGP connection. There is an additional problem in case the value is not reset. Even assumin= g the connection retry is 90s and HoldTimer is 4 mins, when ConnectRetry ti= mer expires in ACTIVE state we don't reset the HoldTimer and move to CONNEC= T state. Ideally if peer is not accepting TCP connections we should remain stuck in = CONNECT state with ConnectRetry counter restarting. But in above path with HoldTimer in some value we would after 1-2 tries cha= nge state back to IDLE state which should not be the case. Thanks, Shashank Tom Petch -Also when moving from OPENSENT to ACTIVE in case of TCP failure the rfc sa= ys to close the BGP connection. Why should the HoldTimer be running without= a BGP connection? Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 7:12 PM To: yakov@juniper.net; tony.li@tony.li; skh@nexthop.com; stbryant@cisco.com= ; adrian@olddog.co.uk; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: Shashank Tyagi; rfc-editor@rfc-editor.org; idr@ietf.org Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) >From the Original Text, I infer that this refers to OpenSent, when event 18 occurs. The Notes say "HoldTimer should only be used to control time in between BGP packets. " This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as we= ll as an OPEN) so the timer should be running. "Also in this case it can lead to case in ACTIVE state where HoldTimer expi= res before the ConnectRetryTimer leading to IDLE state." Well, it will lead to Active state (p.59) - that is what the text says - an= d event 10, HoldTimer expires, will then take you to Idle state (p.63). The expectation is that the HoldTimer has been set to a large value, 4 minu= tes, which is much greater than the ConnectRetryTimer (90s) and it is the e= xpiry of the latter that should take you out of Active state to Connect and= thence to OpenSent when the HoldTimer will be restarted. Note that the receipt of a KEEPALIVE (event 26) also takes you from Active = to Idle - I think that the two cases are similar, that the BGP connection d= id not reach second base. You are in trouble either way and back to Idle i= s the safe thing to do. Of course, if you ignore that advice to set the HoldTimer to a large value = - you have yet to receive an OPEN and so do not know what value will be acc= eptable to the peer - and set it instead to 3s, then yes, you will get back= to Idle more often than is desirable. Nowadays, there is a greater wish to keep BGP connections up, compared to w= hen we wrote RFC4271, but I think that, in this case, there is nothing wort= h keeping up and going back to Idle is the right thing to do. (I am not sure what the best distribution for this is so I have used 'Reply= All' but expect that that should be trimmed soon). Tom Petch ----- Original Message ----- From: "RFC Errata System" To: ; ; ; ; ; ; Cc: ; ; Sent: Wednesday, September 26, 2012 10:06 AM Subject: [Idr] [Technical Errata Reported] RFC4271 (3366) > > The following errata report has been submitted for RFC4271, "A Border=20 > Gateway Protocol 4 (BGP-4)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4271&eid=3D3366 > > -------------------------------------- > Type: Technical > Reported by: Shashank Tyagi > > Section: 8.2.2 > > Original Text > ------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Corrected Text > -------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - sets the HoldTimer to 0, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Notes > ----- > HoldTimer should only be used to control time in between BGP packets. > Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > 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=20 > change the status and edit the report, if necessary. > > -------------------------------------- > RFC4271 (draft-ietf-idr-bgp4-26) > -------------------------------------- > Title : A Border Gateway Protocol 4 (BGP-4) > Publication Date : January 2006 > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > Category : DRAFT STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From ietfc@btconnect.com Fri Oct 5 04:12:06 2012 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 040AE21F86DF for ; Fri, 5 Oct 2012 04:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-YUCkZwUXRK for ; Fri, 5 Oct 2012 04:12:04 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC4021F8562 for ; Fri, 5 Oct 2012 04:12:03 -0700 (PDT) Received: from mail104-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 11:12:03 +0000 Received: from mail104-co1 (localhost [127.0.0.1]) by mail104-co1-R.bigfish.com (Postfix) with ESMTP id 448C718013A; Fri, 5 Oct 2012 11:12:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz9371I1102I542M1432I1418I4015Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh172cdfhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h304l1155h) Received: from mail104-co1 (localhost.localdomain [127.0.0.1]) by mail104-co1 (MessageSwitch) id 1349435521450784_18127; Fri, 5 Oct 2012 11:12:01 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.228]) by mail104-co1.bigfish.com (Postfix) with ESMTP id 67E2688005D; Fri, 5 Oct 2012 11:12:01 +0000 (UTC) Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (157.56.253.85) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 5 Oct 2012 11:11:59 +0000 Received: from CH1PRD0410HT001.namprd04.prod.outlook.com (157.56.244.181) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.207.9; Fri, 5 Oct 2012 11:11:57 +0000 Message-ID: <00c001cda2ea$3f7399c0$4001a8c0@gateway.2wire.net> From: t.petch To: Shashank Tyagi , , , , RFC Errata System References: <20120926090655.84AD3B1E002@rfc-editor.org> <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> <04d601cda0b7$d70b1720$4001a8c0@gateway.2wire.net> <000901cda18b$816c58e0$4001a8c0@gateway.2wire.net> <023f01cda220$ebd265e0$4001a8c0@gateway.2wire.net> Date: Fri, 5 Oct 2012 12:11:51 +0100 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-Originating-IP: [157.56.244.181] X-FOPE-CRA-Verdict: 157.56.253.85$juniper.net%12218%4%btconnect.com%False%True%0$ X-OriginatorOrg: btconnect.com Cc: idr Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) 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, 05 Oct 2012 11:12:06 -0000 ----- Original Message ----- From: "Shashank Tyagi" To: "t.petch" ; ; ; ; "RFC Errata System" Cc: "idr" Sent: Thursday, October 04, 2012 5:35 PM Hi Tom, Few comments inline. And I still think that for all scenarios that you've suggested so far HOLDTIMER is not the right approach and other approaches already exist :) Also I feel we can converge on this faster if we can have a quick chat than on mails. If you still strongly feel that having HOLDTIMER running in ACTIVE or CONNECT state without any bgp connection is important and correct and if others also feel the same then please send me your final comments for rejecting the errata. Shashank I do feel that having HoldTimer running in Active or Connect is valid provided we have come from OpenSent, that is we got so far but no further. I agree that an alternative is to revert from OpenSent to Idle on event 18 at that point, but that is not what was decided when RFC4271 was being produced and I do not see a good engineering reason to change it at this stage. Stepping back, the idr list, which is the home for matters BGP in the IETF, has likely a cast of thousands any of whom can express an opinion on this, an opinion which the AD will consider when deciding whether or not to accept the Erratum. I think it is time for me to step aside and encourage others to speak up. On a matter of process, I do think that what you are proposing is not an Erratum as the IETF sees it but an engineering change, something to be discussed on the idr list which, if it commands support, could lead to an I-D and an RFC. As you gather, I think otherwise but my voice is only one among a large number. I would urge you, assuming you have an ongoing interest in BGP, to join the idr list, to look at the public archives; you can, for example, go back in the archives to 1998 and see some of the discussions that led to RFC4271 (although I cannot recall any on this particular point). Tom Petch Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Thursday, October 4, 2012 4:34 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: idr Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) ---- Original Message ----- From: "Shashank Tyagi" To: "t.petch" ; ; ; ; "RFC Errata System" Cc: "idr" Sent: Wednesday, October 03, 2012 7:16 PM Hi Tom, My message wont reach idr list without approval so please forward (or reply back) if necessary. Keeping them in cc. Few quick notes: -Completely agree about the HoldTimer point. -Whether we lose the TCP or not we rely on the stack for that. If stack returns the failure then we take it as TCP fail. Even a TCP FIN is taken as a failure. Also while moving to ACTIVE state we close the BGP connection and wait in ACTIVE for sometime (ConnectRetryTimer) and then try to establish the connection again. If it does go through then HoldTimer is reset. Agree about your interpretation for this point as well. -Even in the current specification we can go around this loop infinitely as long as ConnectRetryTimer expires before the HoldTimer as we reset it each time before moving on to OpenSent. So I disagree with using the HoldTimer for stopping infinite loop. -To add to above for this purpose of stopping infinite loops or some restrictions the implementation could use the CONNECTRETRYCOUNTER which is meant for this. -Even without the above TCPFail case when trying to connect to peer (who may be inactive or unreachable) we are in infinite loop of CONNECT and ACTIVE. The only place we go back to IDLE is two consecutive TCP Fail one of which must occur in ACTIVE state. Again to stop infinite loop if interested the implementation should use CONNECTRETRYCOUNTER. -KeepAlive is irrelevant so we can drop it from discussions. Shashank You say that we are dependent on the stack for knowing whether or not TCP is up, but in the general case, this is obviously untrue, else we would never have KEEPALIVE - TCP often does not notice rock solid Layer 2 failures and whilst a false report of TCP failing is rare, I expect it happens as well. The application must take care of itself regardless of what TCP says. Whatever be the scenario this can be out of scope here. Also the implementation of KEEPALIVE is also required in valid cases where the BGP fails but not the underlying TCP. But the cases youre saying are possible as well but in that case where TCP fails and stack fails to inform us about it we remain in the OPENSENT state where HOLDTIMER is perfectly valid and will take care of any such failure/scenario. You say that ConnectRetryCounter is intended to stop loops but that is not what the FSM says - I see no event to the effect that the ConnectRetryCounter has exceeded some value and it is time to drop the session; rather, the FSM depends on timers and their expiry. No it doesn't but neither does the RFC give any other purpose for maintaining the counter. As far as my understanding goes it CAN (if implementation wants to stop loops) be used to stop loops after a time but if you have a better understanding or use for it then please share. Cycling between Active and Connect never having got further I am comfortable with; we may have to wait a long time for the peer to become available and we have yet to reach first base. Cycling between Active and Connect having sent an OPEN, which probably arrived which could mean the peer thinks we have received an OPEN and are in OpenConfirm I am not comfortable with - we SHOULD NOT stay there for long and HoldTimer expiry is the way out. While what youre saying is correct it is more for finding out some purpose of the HoldTimer in this state. Few points about this: -The scenario you described says that the PEER-FSM might have reached OpenSent/Confirm state and thinks we are also in different state (than ACTIVE). Then this will be handled by the HoldTimer running on the PEER if the TCP fail was not real (or not communicated to the peer). FSM on one side should not be having anything which detects problems in PEER-FSM. -If we don't want to retry connecting to the peer in case of TCP failure from OPENSENT state then why on Event 18 we don't just go to IDLE like we go from OPENCONFIRM or ESTABLISHED? Going back to ACTIVE means that we are interested in trying to connect to the peer again. If the TCP is really flaky or due to some error the TCP failure occurs twice simultaneously then only should we be going to IDLE state from ACTIVE state and not based on value of HOLDTIMER. I think the current specification has it right:-) Tom Petch Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Wednesday, October 3, 2012 10:51 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: idr Shashank I remain confused. You say below [shtyagi] In my opinion the hold timer should not have any role unless the FSM thinks the BGP connection is active. The hold timer is only intended to check for activity in BGP session. My current (a bit rusty) thinking is that the HoldTimer is set when moving to OpenSent, OpenConfirm, Established states. Moving to OpenSent it is set to a large value (e.g. 4 minutes) and if it expires, we revert to Idle. If we lose the TCP connection, and this is something that the BGP engine cannot reliably know - that is the nature of TCP stacks - then we do not immediately give up but go back to Active, wait for the ConnectRetryTimer to expire, start a TCP connection, move to Connect and wait for success with TCP (again); we can then go back to OpenSent and restart the HoldTimer. But we can also stay in Active/Connect for ConnectRetryTimer and DelayOpenTimer one or more times and on TCP failure in Connect go back to Active. What I think that you are proposing is that this can go on for ever. What the current specification says is that if you have been going round this loop for a large amount of time without success, then it is time to give up. I think the current specification has it right. As you gather, my first reply misread the FSM thinking that a KEEPALIVE had been sent when it had not, but that was also irrelevant; the idea of the HoldTimer being there to clean things up has not changed. Tom Petch ----- Original Message ----- From: "Shashank Tyagi" To: "t.petch" ; ; ; ; "RFC Errata System" Sent: Tuesday, October 02, 2012 5:36 PM -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 9:35 PM To: Shashank Tyagi; stbryant@cisco.com; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: idr@ietf.org ----- Original Message ----- From: "Shashank Tyagi" Sent: Tuesday, October 02, 2012 2:59 PM Hi Tom, Thanks for your reply. Yes it refers to OpenSent state sorry forgot to mention that. Few comments: -In OpenSent the KEEPALIVE has not been sent, only the Open message has been sent. So there would be no receipt of KEEPALIVE. Right, you are confusing me:-( Your proposed change was to set the HoldTimer to 0 when transitioning from OpenSent state to Active which made me think that a KEEPALIVE had been sent and the HoldTimer could be running in OpenSent and I thought I had found such a case in the FSM this morning. Looking again, I cannot find it so assume that no KEEPALIVE has been sent (I was probably reading OpenConfirm). [shtyagi] Probably OpenConfirm :) What then is your suggested change for the receipt of event 18 in OpenSent? To stop the HoldTimer if it is running? To ensure that the next use of the HoldTimer has a zero value and so is not started? Or what? [shtyagi] Yes to set the value to 0. Whenever the TCP is established again (in either ACTIVE state or CONNECT state) and OPEN Message sent out the Hold Timer Will get activated again. The FSM is intended to be robust in the event of all possibilities, including implementation errors, with the default being, when something completely impossible happens, go back to Idle state. In fact, there are an awful lot of corner cases arising out of such as connection collisions, of data being buffered in the TCP stack when BGP thinks there is no connection, TCP connection dropping and either noone noticing or restarting etc so even a perfect implementation can do some strange things. If, thus, the HoldTimer expires in Active state, the only thing to do IMHO is to revert to Idle (and call your software supplier if you are sure it cannot happen:-) - as I said before, the expectation is that the ConnectRetryTimer will expire first taking it back to OpenSent. [shtyagi] In my opinion the hold timer should not have any role unless the FSM thinks the BGP connection is active. The hold timer is only intended to check for activity in BGP session. All the corner cases that you have mentioned above are already being handled in the FSM. BGP packets in queue after TCP failure if received in ACTIVE state will be discarded with state changed to IDLE. Am suggesting to only turn of the Hold Timer only after we decide the TCP has failed and we are closing the BGP connection. There is an additional problem in case the value is not reset. Even assuming the connection retry is 90s and HoldTimer is 4 mins, when ConnectRetry timer expires in ACTIVE state we don't reset the HoldTimer and move to CONNECT state. Ideally if peer is not accepting TCP connections we should remain stuck in CONNECT state with ConnectRetry counter restarting. But in above path with HoldTimer in some value we would after 1-2 tries change state back to IDLE state which should not be the case. Thanks, Shashank Tom Petch -Also when moving from OPENSENT to ACTIVE in case of TCP failure the rfc says to close the BGP connection. Why should the HoldTimer be running without a BGP connection? Thanks, Shashank -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, October 02, 2012 7:12 PM To: yakov@juniper.net; tony.li@tony.li; skh@nexthop.com; stbryant@cisco.com; adrian@olddog.co.uk; shares@ndzh.com; jgs@juniper.net; RFC Errata System Cc: Shashank Tyagi; rfc-editor@rfc-editor.org; idr@ietf.org Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (3366) >From the Original Text, I infer that this refers to OpenSent, when event 18 occurs. The Notes say "HoldTimer should only be used to control time in between BGP packets. " This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as well as an OPEN) so the timer should be running. "Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state." Well, it will lead to Active state (p.59) - that is what the text says - and event 10, HoldTimer expires, will then take you to Idle state (p.63). The expectation is that the HoldTimer has been set to a large value, 4 minutes, which is much greater than the ConnectRetryTimer (90s) and it is the expiry of the latter that should take you out of Active state to Connect and thence to OpenSent when the HoldTimer will be restarted. Note that the receipt of a KEEPALIVE (event 26) also takes you from Active to Idle - I think that the two cases are similar, that the BGP connection did not reach second base. You are in trouble either way and back to Idle is the safe thing to do. Of course, if you ignore that advice to set the HoldTimer to a large value - you have yet to receive an OPEN and so do not know what value will be acceptable to the peer - and set it instead to 3s, then yes, you will get back to Idle more often than is desirable. Nowadays, there is a greater wish to keep BGP connections up, compared to when we wrote RFC4271, but I think that, in this case, there is nothing worth keeping up and going back to Idle is the right thing to do. (I am not sure what the best distribution for this is so I have used 'Reply All' but expect that that should be trimmed soon). Tom Petch ----- Original Message ----- From: "RFC Errata System" To: ; ; ; ; ; ; Cc: ; ; Sent: Wednesday, September 26, 2012 10:06 AM Subject: [Idr] [Technical Errata Reported] RFC4271 (3366) > > The following errata report has been submitted for RFC4271, "A Border > Gateway Protocol 4 (BGP-4)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3366 > > -------------------------------------- > Type: Technical > Reported by: Shashank Tyagi > > Section: 8.2.2 > > Original Text > ------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Corrected Text > -------------- > If a TcpConnectionFails event (Event 18) is received, the local > system: > > - closes the BGP connection, > > - sets the HoldTimer to 0, > > - restarts the ConnectRetryTimer, > > - continues to listen for a connection that may be initiated by > the remote BGP peer, and > > - changes its state to Active. > > Notes > ----- > HoldTimer should only be used to control time in between BGP packets. > Also in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state. > > 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. > > -------------------------------------- > RFC4271 (draft-ietf-idr-bgp4-26) > -------------------------------------- > Title : A Border Gateway Protocol 4 (BGP-4) > Publication Date : January 2006 > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > Category : DRAFT STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From iesg-secretary@ietf.org Fri Oct 5 11:24:07 2012 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 7205121F8766; Fri, 5 Oct 2012 11:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgk3MJX1t49Z; Fri, 5 Oct 2012 11:24:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEBC21F8555; Fri, 5 Oct 2012 11:24:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121005182400.19051.64136.idtracker@ietfa.amsl.com> Date: Fri, 05 Oct 2012 11:24:00 -0700 Cc: idr mailing list , idr chair , RFC Editor Subject: [Idr] Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard (draft-ietf-idr-rfc4893bis-07.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, 05 Oct 2012 18:24:07 -0000 The IESG has approved the following document: - 'BGP Support for Four-octet AS Number Space' (draft-ietf-idr-rfc4893bis-07.txt) as Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis/ Technical Summary The Autonomous System (AS) number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. The primary difference between RFC 4893 and this draft is the introduction of a detailed Error Handling section. Several other requirements are also clarified or added. Working Group Summary One working group member, John Leslie, contributed a detailed review of the draft which suggested extensive changes in terminology. The authors disagreed as to the need for the changes. When the chairs put the question to the WG directly, there was no support for pushing forward with the changes, and some opposition. During IETF Last Call one reviewer objected to the paragraph in section 6 stating : "In addition, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute of an UPDATE message. A NEW BGP speaker that receives these path segment types in the AS4_PATH attribute of an UPDATE message from an OLD BGP speaker MUST discard these path segments, adjust the relevant attribute fields accordingly, and continue processing the UPDATE message. This case SHOULD be logged locally for analysis." There was no support for this position and several emails validating its inclusion. Document Quality The protocol (extension) has been implemented and fielded for years and it is generally considered to be a requirement for a serious BGP implementation. Personnel The Document Shepherd is John Scudder. The Responsible Area Director is Stewart Bryant. RFC Editor Note In the metadata please add "Updates: RFC4271" ===== In the Abstract Old This document obsoletes RFC 4893. New This document obsoletes RFC 4893 and updates RFC4271 End ===== Before section 8 add a new section with the following title and text: Manageability Considerations If BGP-4 MIB [RFC4273] is supported, there are no additional manageability concerns that arise with from the use of four octet AS numbers, since the InetAutonomousSystemNumber textual convention is defined as an unsigned32. When IPFIX export [RFC5101] is supported, there are no additional manageability concerns that arise from the use of four octet AS numbers. The bgpSourceAsNumber and bgpDestinationAsNumber information elements [http://www.iana.org/assignments/ipfix/ipfix.xml] can continued to be used, with a new template record, specifying the new length of 4 bytes. === Please add informational reference [http://www.iana.org/assignments/ipfix/ipfix.xml] === At the end of the Introduction OLD: This document obsoletes RFC 4893, and a comparison with RFC 4893 is provided in Appendix A. NEW: This document obsoletes RFC 4893. It includes several clarifications and editorial changes, and specifies the error handling for the new attributes. END === Please delete Appendix A === From jgs@juniper.net Thu Oct 11 08:29:25 2012 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 3516521F84F9 for ; Thu, 11 Oct 2012 08:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-1.692, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_2=2.5, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id su9pzQYXqYLn for ; Thu, 11 Oct 2012 08:29:23 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 93F1721F870A for ; Thu, 11 Oct 2012 08:29:23 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUHbl0zVDtbDA4c+hQkHrndSOU2WiV3gr@postini.com; Thu, 11 Oct 2012 08:29:23 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Oct 2012 08:29:04 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 11 Oct 2012 08:29:03 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.189) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 11 Oct 2012 08:30:39 -0700 Received: from mail47-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 11 Oct 2012 15:29:01 +0000 Received: from mail47-co1 (localhost [127.0.0.1]) by mail47-co1-R.bigfish.com (Postfix) with ESMTP id BEFAA3400B7 for ; Thu, 11 Oct 2012 15:29:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371I1454I1432I4015Izz1202h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h946hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1155h) Received: from mail47-co1 (localhost.localdomain [127.0.0.1]) by mail47-co1 (MessageSwitch) id 1349969339534233_10277; Thu, 11 Oct 2012 15:28:59 +0000 (UTC) Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.235]) by mail47-co1.bigfish.com (Postfix) with ESMTP id 7E80F400066; Thu, 11 Oct 2012 15:28:59 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 11 Oct 2012 15:28:57 +0000 Received: from sa-nc-it-117.static.jnpr.net (66.129.224.53) by pod51010.outlook.com (10.255.150.39) with Microsoft SMTP Server (TLS) id 14.16.207.9; Thu, 11 Oct 2012 15:28:54 +0000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: "John G. Scudder" In-Reply-To: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> Date: Thu, 11 Oct 2012 11:28:50 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <000001cd7ee2$1ea06830$5be13890$@ndzh.com> To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1498) X-Originating-IP: [66.129.224.53] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%NDZH.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%MICROSOFT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Hares Susan , "Jon Mitchell \(GNS\)" Subject: Re: [Idr] Call for adoption of draft-mitchell-idr-private-as-reservation-01 as IDR WG document 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, 11 Oct 2012 15:29:25 -0000 This draft is accepted as an IDR WG document. Jon, please resubmit as draft-ietf-idr-private-as-reservation-00. Feel = free to update out-of-date references before resubmitting, as needed = (and anything else needed to make idnits feel happy). Thanks, --John and Sue On Aug 20, 2012, at 10:43 AM, Susan Hares wrote: > IDR WG: > =20 > This is call for adoption of > =20 > draft-mitchell-idr-private-as-reservation-01 > =20 > as a working group draft, > =20 > Location: > =20 > = http://tools.ietf.org/html/draft-mitchell-idr-as-private-reservation-01 > =20 > =20 > Vote early and often (smile) > =20 > Cheers, > =20 > IDR Chairs =96 Sue and John From internet-drafts@ietf.org Thu Oct 11 15:08:31 2012 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 694BD11E8097; Thu, 11 Oct 2012 15:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-6ephc3i7XF; Thu, 11 Oct 2012 15:08:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA9D21F850B; Thu, 11 Oct 2012 15:08:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121011220830.1166.84099.idtracker@ietfa.amsl.com> Date: Thu, 11 Oct 2012 15:08:30 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-private-reservation-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: Thu, 11 Oct 2012 22:08:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Autonomous System (AS) Reservation for Private Use Author(s) : Jon Mitchell Filename : draft-ietf-idr-as-private-reservation-00.txt Pages : 4 Date : 2012-10-11 Abstract: This document describes the reservation of Autonomous System numbers (ASNs) that are for private use only and should not be advertised to the Internet, known as private use ASNs. This document enlarges the total space available for private use ASNs by documenting the reservation of a second, larger range and updates RFC 1930. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jgs@juniper.net Fri Oct 12 08:21:40 2012 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 B6B1B21F8687 for ; Fri, 12 Oct 2012 08:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.824 X-Spam-Level: X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bltak1FNEm2L for ; Fri, 12 Oct 2012 08:21:39 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id EB41321F865E for ; Fri, 12 Oct 2012 08:21:38 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUHg1gm163WxiX7GpwbCTBjaO58VRtj5h@postini.com; Fri, 12 Oct 2012 08:21:39 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 12 Oct 2012 08:21:37 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 12 Oct 2012 08:21:36 -0700 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.142) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 12 Oct 2012 08:27:56 -0700 Received: from mail102-db3-R.bigfish.com (10.3.81.229) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 12 Oct 2012 15:21:31 +0000 Received: from mail102-db3 (localhost [127.0.0.1]) by mail102-db3-R.bigfish.com (Postfix) with ESMTP id 31F6E20127 for ; Fri, 12 Oct 2012 15:21:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -6 X-BigFish: PS-6(zz98dI9371Ic85fh1432I1519M4015Izz1202h1d1ah1d2ah1082kzz8275chz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah139eh1441h1155h) Received: from mail102-db3 (localhost.localdomain [127.0.0.1]) by mail102-db3 (MessageSwitch) id 1350055288649811_6357; Fri, 12 Oct 2012 15:21:28 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.239]) by mail102-db3.bigfish.com (Postfix) with ESMTP id 9A05142009A for ; Fri, 12 Oct 2012 15:21:28 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Oct 2012 15:21:28 +0000 Received: from sa-nc-it-117.static.jnpr.net (66.129.224.50) by pod51010.outlook.com (10.255.84.40) with Microsoft SMTP Server (TLS) id 14.16.207.9; Fri, 12 Oct 2012 15:21:27 +0000 From: "John G. Scudder" Content-Type: multipart/alternative; boundary="Apple-Mail=_3EDECD45-D49C-4755-960F-C24C2C372CF9" Message-ID: MIME-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Date: Fri, 12 Oct 2012 11:21:24 -0400 References: <3B75DB6F-3FF2-4451-8387-1FABD7A16A7A@juniper.net> <1297C2FC-C407-4FBC-BA17-195C1F169EED@juniper.net> To: "idr@ietf.org List" In-Reply-To: <1297C2FC-C407-4FBC-BA17-195C1F169EED@juniper.net> X-Mailer: Apple Mail (2.1498) X-Originating-IP: [66.129.224.50] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [Idr] IETF-85 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: Fri, 12 Oct 2012 15:21:40 -0000 --Apple-Mail=_3EDECD45-D49C-4755-960F-C24C2C372CF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Reminder: Deadline for agenda topics is ten days from now. So far we have requests from Ahmed and Pierre. --John On Aug 27, 2012, at 5:31 PM, John Scudder wrote: > Also, if you request a slot, please provide an estimate of how much = time you think you'll need, or if you don't have a clue yet, say so and = we'll check back closer to the meeting date. >=20 > Thanks, >=20 > --John >=20 > On Aug 23, 2012, at 5:34 PM, John Scudder wrote: >=20 >> Folks, >>=20 >> (I know it seems as though IETF-84 just ended, but it seemed worth = asking for topics early rather than late, if only for the sake of = variety. I'll send a reminder closer to the date.) >>=20 >> We're planning to meet at IETF-85. Scheduling is TBD. Please = forward any IDR agenda items you might have to Sue and myself. The = deadline is Monday, October 22 by 13:00 U.S. Eastern Time, although = earlier is better. Priority will be given to those who get their = requests in before the deadline. >>=20 >> If you have previously presented on your topic at an IDR meeting, = please explain in your request what you hope to achieve with your = presentation this time. >>=20 >> 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 slides to Sue and me no later than 24 hours prior to the = meeting. Slides will be converted to PDF and projected from the chairs' = laptop, unless you make other arrangements well in advance. >>=20 >> Finally, if you request an agenda slot, please do so by replying to = this message and don't change the subject line. >>=20 >> Thanks, >>=20 >> --John & Sue --Apple-Mail=_3EDECD45-D49C-4755-960F-C24C2C372CF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" jgs@juniper.net> wrote:
Also, if = you request a slot, please provide an estimate of how much time you = think you'll need, or if you don't have a clue yet, say so and we'll = check back closer to the meeting = date.

Thanks,

--John

On Aug 23, 2012, at 5:34 PM, = John Scudder wrote:

Folks,

(I = know it seems as though IETF-84 just ended, but it seemed worth asking = for topics early rather than late, if only for the sake of variety. I'll = send a reminder closer to the date.)

We're planning to meet at = IETF-85.  Scheduling is TBD.  Please forward any IDR agenda = items you might have to Sue and myself.  The deadline is Monday, = October 22 by 13:00 U.S. Eastern Time, although earlier is better. =  Priority will be given to those who get their requests in before = the deadline.

If you have previously presented on your topic at = an IDR meeting, please explain in your request what you hope to achieve = with your presentation this time.

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 slides to Sue = and me no later than 24 hours prior to the meeting.  Slides will be = converted to PDF and projected from the chairs' laptop, unless you make = other arrangements well in advance.

Finally, if you request an = agenda slot, please do so by replying to this message and don't change = the subject line.

Thanks,

--John & = Sue

= --Apple-Mail=_3EDECD45-D49C-4755-960F-C24C2C372CF9-- From randy@psg.com Mon Oct 15 11:08:29 2012 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 579AE21F88A3 for ; Mon, 15 Oct 2012 11:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk3qnKy6zyeM for ; Mon, 15 Oct 2012 11:08:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id ED61421F88A2 for ; Mon, 15 Oct 2012 11:08:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TNp5Y-000ExN-7S for idr@ietf.org; Mon, 15 Oct 2012 18:08:28 +0000 Date: Mon, 15 Oct 2012 08:08:27 -1000 Message-ID: From: Randy Bush To: idr wg References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: [Idr] draft-ymbk-l3vpn-origination-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 18:08:29 -0000 Filename: draft-ymbk-l3vpn-origination Revision: 00 Title: Authenticating L3VPN Origination Signaling Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-ymbk-l3vpn-origination-00.txt Status: http://datatracker.ietf.org/doc/draft-ymbk-l3vpn-origination Htmlized: http://tools.ietf.org/html/draft-ymbk-l3vpn-origination-00 Abstract: A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are subject to unintentional errors, both by the legitimate originator and by non-legitimate origins. This is of special concern if the VPN traverses untrusted networks. This document describes how the sender of the VPN/Prefix binding may sign it so that recipient of the binding may authenticate it. From rraszuk@gmail.com Mon Oct 15 20:29:10 2012 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 D4B891F0C9D; Mon, 15 Oct 2012 20:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNXi4caJUZKu; Mon, 15 Oct 2012 20:29:10 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 354651F0C9C; Mon, 15 Oct 2012 20:29:10 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so10442959iec.31 for ; Mon, 15 Oct 2012 20:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=I7qEi++gnPDTqvsOg7qs26KUtLTGJKBc/fgAo4Z/rv0=; b=gctaeKugVpmNiu2iKpFXxQTGB9CIbtPY02tpENKVij9fzo2RXsj7dTOBmOdRJSHRDa xp3RupJywKlR9eY13swA9dqaSuOd8zd/uGHjt58ysHliJEgSoOj/wA4KoIO1RL4SpJEp hEk56GJT6/RKgIv+rRHMxOVQ76UmyVR0ZXjOhsur31qdl0IuBEsOzjhygU0FHetMFkRo ghlDvF4b/15HlVM430KFIZtEkOkNtG2zguvn2dtHpAPKeOwM4aCLUIqoNmD+IQBkPgeF JPAxqdkt8tdzQXCtsV6L5yc3bZeOkzYZZbxV50WqlWcmnJcMeCkuOSpFnGy7t+bvASsl vCvw== MIME-Version: 1.0 Received: by 10.50.47.201 with SMTP id f9mr10605018ign.44.1350358149757; Mon, 15 Oct 2012 20:29:09 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Mon, 15 Oct 2012 20:29:09 -0700 (PDT) In-Reply-To: References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 05:29:09 +0200 X-Google-Sender-Auth: kZuKcMrqQC4KRNsKGNbk242b7aA Message-ID: From: Robert Raszuk To: Randy Bush , keyupate@cisco.com, pmehta@cisco.com, asreekan@cisco.com, luay.jalil@verizon.com Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , L3VPN Subject: Re: [Idr] draft-ymbk-l3vpn-origination-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, 16 Oct 2012 03:29:11 -0000 Dear authors, I have one doubt regarding this proposal ... Abstract says: "This document describes how the sender of the VPN/Prefix binding may sign it so that recipient of the binding may authenticate it." I highly agree that this would be useful to address. However just going to introduction section we find: This document describes how the originating PE, West, may sign the announcement so that the destination PE, East, may authenticate the NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] Let me point out that West PE is not the originator of the route advertisement .. neither East PE is the destination. Originator and destination are corresponding CEs on both sides. With this in mind let me also point out that RFC4364 VPN sites very often use private addresses which are never part of any public RPKI for one simple reason that public RPKI has no notion of RDs to make such prefixes unique. Last let me point out also that RFC4364 defines CSC interconnect model which this draft also does not comment on. With this in mind I find the document quite incomplete at it's current form to progress it further. Also I think l3vpn WG should be cc-ed on this thread. Best regards, R. On Mon, Oct 15, 2012 at 8:08 PM, Randy Bush wrote: > Filename: draft-ymbk-l3vpn-origination > Revision: 00 > Title: Authenticating L3VPN Origination Signaling > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 6 > URL: http://www.ietf.org/internet-drafts/draft-ymbk-l3vpn-origination-00.txt > Status: http://datatracker.ietf.org/doc/draft-ymbk-l3vpn-origination > Htmlized: http://tools.ietf.org/html/draft-ymbk-l3vpn-origination-00 > > > Abstract: > A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are > subject to unintentional errors, both by the legitimate originator > and by non-legitimate origins. This is of special concern if the VPN > traverses untrusted networks. This document describes how the sender > of the VPN/Prefix binding may sign it so that recipient of the > binding may authenticate it. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Mon Oct 15 20:41:58 2012 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 22B2021F86E4; Mon, 15 Oct 2012 20:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y95Kd5iREG3Q; Mon, 15 Oct 2012 20:41:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3E121F851A; Mon, 15 Oct 2012 20:41:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TNy2T-000H49-N1; Tue, 16 Oct 2012 03:41:54 +0000 Date: Mon, 15 Oct 2012 17:41:52 -1000 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , L3VPN , luay.jalil@verizon.com, keyupate@cisco.com Subject: Re: [Idr] draft-ymbk-l3vpn-origination-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, 16 Oct 2012 03:41:58 -0000 thanks for review! > This document describes how the originating PE, West, may sign the > announcement so that the destination PE, East, may authenticate the > NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] > > Let me point out that West PE is not the originator of the route > advertisement .. neither East PE is the destination. Originator and > destination are corresponding CEs on both sides. good catch! > With this in mind let me also point out that RFC4364 VPN sites very > often use private addresses which are never part of any public RPKI > for one simple reason that public RPKI has no notion of RDs to make > such prefixes unique. if they want to use the rpki, then, just as other rpki publishers using 1918 space, they would have local trust anchors and certify the private space. see draft-ietf-sidr-ltamgmt. > Last let me point out also that RFC4364 defines CSC interconnect model > which this draft also does not comment on. more specific cite, please? thanks. randy From rraszuk@gmail.com Mon Oct 15 21:03:32 2012 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 4B7AD11E8142; Mon, 15 Oct 2012 21:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW4VOSvfrMPA; Mon, 15 Oct 2012 21:03:31 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACA7D11E8138; Mon, 15 Oct 2012 21:03:31 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so4905917iad.31 for ; Mon, 15 Oct 2012 21:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JK86SH99fmgI10eSinEIz2VirxNrUDZrspG5pBE+Rvc=; b=aBGoykO8zVcQKcS2BBXJryOvR1aVfQjja8Zx1Al685TctxZZecb2B+Bx4SW0+Dl6mR Yir9FkQm+yjUdWOYPAK0vbYBkBq9CiQTu+6tge1n8VHhlYTrYQBm6A5j3bc2hHk2CDE2 K3ZRlrnb9JLk1oD/D0biLmSj2tlxdVJY77woElJZJe3+FD38JXAB83Rw1YR4Ng5Lxm5P 9sfyQb6uOY6Pb+OOXygN7Tgy43otjbwAKvUGKXJDLVA30SP5dSpCZJoJbdHjUM7rvamV wgBrQdeK1Ka3x48NVSWA1sqqm8MmrZGJ5lgZxat3VXrQlxcDldIRfd8DSgXvZoORp+EF yBCQ== MIME-Version: 1.0 Received: by 10.50.15.193 with SMTP id z1mr10833579igc.47.1350360211169; Mon, 15 Oct 2012 21:03:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Mon, 15 Oct 2012 21:03:31 -0700 (PDT) In-Reply-To: References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 06:03:31 +0200 X-Google-Sender-Auth: sTKzOpe00_lIqwSf0a20kr0wAg0 Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , L3VPN , luay.jalil@verizon.com, keyupate@cisco.com Subject: Re: [Idr] draft-ymbk-l3vpn-origination-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, 16 Oct 2012 04:03:32 -0000 Hello Randy, On Tue, Oct 16, 2012 at 5:41 AM, Randy Bush wrote: > thanks for review! You are very welcome ! >> This document describes how the originating PE, West, may sign the >> announcement so that the destination PE, East, may authenticate the >> NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] >> >> Let me point out that West PE is not the originator of the route >> advertisement .. neither East PE is the destination. Originator and >> destination are corresponding CEs on both sides. > > good catch! I was not that much fishing here ... just trying to understand if you are validating CE-CE or PE-PE. If the latter I unfortunately think there is much less of the value. When we originally started to roll out 2547 there was very clear consensus that real protection must happen on the CE-CE boundary. Trusting SP where anyone who logs into PE can do anything for any VPN there was never taken serious. Note that the draft could also allow both, but this needs to be clearly stated in the text. >> With this in mind let me also point out that RFC4364 VPN sites very >> often use private addresses which are never part of any public RPKI >> for one simple reason that public RPKI has no notion of RDs to make >> such prefixes unique. > > if they want to use the rpki, then, just as other rpki publishers using > 1918 space, they would have local trust anchors and certify the private > space. see draft-ietf-sidr-ltamgmt. And what happens in the event of PE-PE validation where only one SP of L3VPN subscribes to RPKI business ? >> Last let me point out also that RFC4364 defines CSC interconnect model >> which this draft also does not comment on. > > more specific cite, please? thanks. http://tools.ietf.org/html/rfc4364#section-9 Summary ... PEs are not involved in distribution of customer routes between customer sites. R. > randy From randy@psg.com Mon Oct 15 21:09:40 2012 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 1377521F86C3; Mon, 15 Oct 2012 21:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SVtCiig9tF2; Mon, 15 Oct 2012 21:09:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id AC31821F86BB; Mon, 15 Oct 2012 21:09:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TNyTJ-000H9B-5X; Tue, 16 Oct 2012 04:09:37 +0000 Date: Mon, 15 Oct 2012 18:09:35 -1000 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , L3VPN , luay.jalil@verizon.com, keyupate@cisco.com Subject: Re: [Idr] draft-ymbk-l3vpn-origination-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, 16 Oct 2012 04:09:40 -0000 > I was not that much fishing here ... just trying to understand if you > are validating CE-CE or PE-PE. If the latter I unfortunately think > there is much less of the value. > > When we originally started to roll out 2547 there was very clear > consensus that real protection must happen on the CE-CE boundary. > Trusting SP where anyone who logs into PE can do anything for any VPN > there was never taken serious. > > Note that the draft could also allow both, but this needs to be > clearly stated in the text. it tries to make that pretty clear This document describes how the originating PE, West, may sign the announcement so that the destination PE, East, may authenticate the NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] Section 4.3.1. Alternatively, the originating CE router may sign the announcement so that the destination CE router may authenticate the NLRI. >> if they want to use the rpki, then, just as other rpki publishers >> using 1918 space, they would have local trust anchors and certify the >> private space. see draft-ietf-sidr-ltamgmt. > > And what happens in the event of PE-PE validation where only one SP of > L3VPN subscribes to RPKI business ? then they should not use rpki keying but rather their own key infrastructure using the Key Identifier to index their KI randy From pmehta@cisco.com Tue Oct 16 14:02:49 2012 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 5EC8D11E80E4; Tue, 16 Oct 2012 14:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKlBy67HfR7w; Tue, 16 Oct 2012 14:02:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 523EE11E80D5; Tue, 16 Oct 2012 14:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2387; q=dns/txt; s=iport; t=1350421368; x=1351630968; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ryye2F9C8QFkHRangV/lS+04uSveCmDrXGWnkmpionY=; b=It3LNcX+0jBOy0frQcgyIkDKz9Y6QpQ4mpEnc2u8ssRsBbRQB5p0+tG+ 4RQWEbXUYutQHa3UvrD4k0gYPVDZoLE7QrCmvmlaK6wtEb3RiXl6mh45I hgbN1KeGgpGKTOKHrCsZH81nT0353tzko3pQcy59qgb/7L66Lkgf+Hic0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALjKfVCtJV2Z/2dsb2JhbABFwA2BCIIgAQEBAwESASc/BQcEAgEIEQQBAQsUCQcyFAkIAgQBDQUIGodQAwkFAZsAj1yQRYpoZ4VdYAOkMoFrgm2BXCMY X-IronPort-AV: E=Sophos;i="4.80,595,1344211200"; d="scan'208";a="132326985" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 16 Oct 2012 21:02:48 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9GL2lQ1001898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Oct 2012 21:02:47 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.63]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Tue, 16 Oct 2012 16:02:47 -0500 From: "Pranav Mehta (pmehta)" To: Randy Bush , Robert Raszuk Thread-Topic: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Index: AQHNqwAew0fd+6zQc0WX8IHgfJLNm5e7mp+AgAADjgCAAAYMgIAAAbKAgAC9qHA= Date: Tue, 16 Oct 2012 21:02:46 +0000 Message-ID: <80F8B5888DDE96498217BE8A5C47436F17F611@xmb-rcd-x13.cisco.com> References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.138.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19276.004 x-tm-as-result: No--34.879000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Keyur Patel \(keyupate\)" , L3VPN , "luay.jalil@verizon.com" , idr wg Subject: Re: [Idr] draft-ymbk-l3vpn-origination-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, 16 Oct 2012 21:02:49 -0000 Robert, As Randy already mentioned, Draft already covers an alternate approach wher= e originating CE would sign the announcement and it will come all the way t= o destination CE to authenticate. =20 Alternately this mechanism can also help in Inter-AS scenario. In Inter-AS= scenario, originating CE can sign the announcement and a "trusted" ASBR on= the Inter-AS boundary can authenticate the announcement if customer trusts= one of the two ISPs. In such scenario, ISP may use the Key identifier t= o find the Key associated with the VPN and send unsigned NLRI in its own ne= twork once it is authenticated at ASBR boundary. - Pranav -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Monday, October 15, 2012 9:10 PM To: Robert Raszuk Cc: Keyur Patel (keyupate); Pranav Mehta (pmehta); Arjun Sreekantiah (asree= kan); luay.jalil@verizon.com; idr wg; L3VPN Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt > I was not that much fishing here ... just trying to understand if you=20 > are validating CE-CE or PE-PE. If the latter I unfortunately think=20 > there is much less of the value. >=20 > When we originally started to roll out 2547 there was very clear=20 > consensus that real protection must happen on the CE-CE boundary. > Trusting SP where anyone who logs into PE can do anything for any VPN=20 > there was never taken serious. >=20 > Note that the draft could also allow both, but this needs to be=20 > clearly stated in the text. it tries to make that pretty clear This document describes how the originating PE, West, may sign the announcement so that the destination PE, East, may authenticate the NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] Section 4.3.1. Alternatively, the originating CE router may sign the announcement so that the destination CE router may authenticate the NLRI. >> if they want to use the rpki, then, just as other rpki publishers=20 >> using 1918 space, they would have local trust anchors and certify the=20 >> private space. see draft-ietf-sidr-ltamgmt. >=20 > And what happens in the event of PE-PE validation where only one SP of=20 > L3VPN subscribes to RPKI business ? then they should not use rpki keying but rather their own key infrastructur= e using the Key Identifier to index their KI randy From rraszuk@gmail.com Tue Oct 16 21:47:30 2012 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 515F221F8600; Tue, 16 Oct 2012 21:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUnLGpBqWmij; Tue, 16 Oct 2012 21:47:29 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBB321F8562; Tue, 16 Oct 2012 21:47:29 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so12747957iec.31 for ; Tue, 16 Oct 2012 21:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=c8rIstKeMLmEBHmayDsLF800TFZQjStRTaEcm5Lth0k=; b=MOw4GwEPJ74N8ioGp0/HszCqkgCL1TumR0R+762ygTMbzJpWzYLwfvnb027xfw7jkH MdbzkyaK4zUKHPdHLduCbJvZJqTZpn2juRfse1mV068pLkaeiZUThm+LTFTLC+WJhex/ miQch2iq5S2gkkrXU/dT0SUDh/PImSS9IcwE94D+OWiPqQj2GHVaIRNzj7+4mJXvsDD0 yF1inc3SKfbB82OZS7P7NIRX6vHoqTLbq/CWWzN4/fulMeifG8s4Ey5cgHC1Li8CBnLe q+21zrtA4pk/TQE7Z0+dpixiZ6jh/xGDfwnwGU9SZmTJdWoajaUrm7c5nlII+zFHJETl SJjw== MIME-Version: 1.0 Received: by 10.42.109.194 with SMTP id m2mr13300322icp.48.1350449248933; Tue, 16 Oct 2012 21:47:28 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Tue, 16 Oct 2012 21:47:28 -0700 (PDT) In-Reply-To: <80F8B5888DDE96498217BE8A5C47436F17F611@xmb-rcd-x13.cisco.com> References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> <80F8B5888DDE96498217BE8A5C47436F17F611@xmb-rcd-x13.cisco.com> Date: Wed, 17 Oct 2012 06:47:28 +0200 X-Google-Sender-Auth: XxbdGgdqOlSLZQUWh3J1Z_nF4-M Message-ID: From: Robert Raszuk To: "Pranav Mehta (pmehta)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Keyur Patel \(keyupate\)" , L3VPN , idr wg , "luay.jalil@verizon.com" Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 04:47:30 -0000 Hey Pranav, Do you really believe that each 7-11 or Walmart store will be subscribing to global RPKI or building their own key infrastructure? I do not. It seems few orders of magnitude easier to sign advertisements at the src/spoke and validate signature at the hub site by the same very network admin residing in the enterprise hub location. That is something we should define in BGP for VPNs and not trying to reuse origin validation concept which works well (for what it is designed to do) in the Internet case. Btw ,,, I do not buy any "trusted" ASBR business ;) Best, R. On Tue, Oct 16, 2012 at 11:02 PM, Pranav Mehta (pmehta) wrote: > Robert, > > As Randy already mentioned, Draft already covers an alternate approach wh= ere originating CE would sign the announcement and it will come all the way= to destination CE to authenticate. > > Alternately this mechanism can also help in Inter-AS scenario. In Inter-= AS scenario, originating CE can sign the announcement and a "trusted" ASBR = on the Inter-AS boundary can authenticate the announcement if customer trus= ts one of the two ISPs. In such scenario, ISP may use the Key identifier= to find the Key associated with the VPN and send unsigned NLRI in its own = network once it is authenticated at ASBR boundary. > > - Pranav > > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, October 15, 2012 9:10 PM > To: Robert Raszuk > Cc: Keyur Patel (keyupate); Pranav Mehta (pmehta); Arjun Sreekantiah (asr= eekan); luay.jalil@verizon.com; idr wg; L3VPN > Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt > >> I was not that much fishing here ... just trying to understand if you >> are validating CE-CE or PE-PE. If the latter I unfortunately think >> there is much less of the value. >> >> When we originally started to roll out 2547 there was very clear >> consensus that real protection must happen on the CE-CE boundary. >> Trusting SP where anyone who logs into PE can do anything for any VPN >> there was never taken serious. >> >> Note that the draft could also allow both, but this needs to be >> clearly stated in the text. > > it tries to make that pretty clear > > This document describes how the originating PE, West, may sign the > announcement so that the destination PE, East, may authenticate the > NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364] > Section 4.3.1. Alternatively, the originating CE router may sign the > announcement so that the destination CE router may authenticate the > NLRI. > >>> if they want to use the rpki, then, just as other rpki publishers >>> using 1918 space, they would have local trust anchors and certify the >>> private space. see draft-ietf-sidr-ltamgmt. >> >> And what happens in the event of PE-PE validation where only one SP of >> L3VPN subscribes to RPKI business ? > > then they should not use rpki keying but rather their own key infrastruct= ure using the Key Identifier to index their KI > > randy From shares@ndzh.com Wed Oct 17 09:44:21 2012 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 AC46B21F866D; Wed, 17 Oct 2012 09:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlEh0iM-oA+k; Wed, 17 Oct 2012 09:44:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 43B4C21F866E; Wed, 17 Oct 2012 09:44:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; Received: from SKH2012HPLT (unverified [64.112.195.202]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 9742-1945496 for multiple; Wed, 31 Oct 2012 02:45:14 -0500 From: "Susan Hares" To: , , "'idr mailing list'" , References: <506C2940.2010507@cisco.com> In-Reply-To: <506C2940.2010507@cisco.com> Date: Wed, 17 Oct 2012 12:44:15 -0400 Message-ID: <01d801cdac86$a5819320$f084b960$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01CDAC65.1E73C3B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKYFlSt+lreVufF6fhRaEgWQSZ6nZYo4E3w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: iesg@ietf.org Subject: Re: [Idr] AD statement on draft-ietf-idr-bgp-issues 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, 17 Oct 2012 16:44:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D9_01CDAC65.1E73C3B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stewart: We will approach item 4 and 3 and 3a in parallel. Thank you for the AD Review. Sue From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Wednesday, October 03, 2012 8:02 AM To: idr-chairs@tools.ietf.org; idr mailing list; draft-ietf-idr-bgp-issues@tools.ietf.org Cc: iesg@ietf.org Subject: AD statement on draft-ietf-idr-bgp-issues To the IDR WG, IDR WG Chairs and authors of draft-ietf-idr-bgp-issues: I have performed an Area Director review of draft-ietf-idr-bgp-issues (Issues in Revising BGP-4 (RFC1771 to RFC4271)), and it is my conclusion that, as submitted to me for AD review, this draft is not suitable for publication as an RFC in the IETF Series. Whilst I understand and support the goal of documenting the key design decisions that formed the basis of the BGP RFC4271, the method that the authors have chosen to present this information lacks the efficiency of presentation of information that I believe is required in the IETF RFC Series. The draft is a reproduction of detailed email exchanges that took place on the IDR list in the early part of the last decade, together with a running commentary and conclusion on each point. Within this 170 pages of text there is far too much cruft and irrelevant discussion for me to accept this publication request. As an aside I also have serious concerns at the extent of review that this document has received by the IDR WG. The only commenter during WG Last call states "... I did look at it when it first appeared, in 2005, and put it on the shelf for further study, where it has remained ever since." This in itself gives concerns regarding the method that the authors have chosen to present this information to the reader. I therefore think that IDR WG needs to find another way to record this information for posterity in a archival format. The IDR WG could proceed on a number of paths with this work. I suggest six ways forward here, but others may be also acceptable. 1) The IDR WG could heavily edit the draft so that it presents in a more conventional, significantly shorter format, the essential issues that were resolved and baked into RFC4271. I would sponsor the publication of a significantly reduced, well targeted, document. 2) The IDR WG could deconstruct the issues and record them in the IETF issue tracker software. This is a method that other WGs have used to address this problem. I accept that this was not possible when the draft was first written in 2003, and that this approach would be a great deal of work. We would have to verify the degree to which this approach matched the archival requirements of the IDR WG. 3) The IDR WG could make some minor modifications and publish this text on an IETF web page with a permanent URL. 3a) The IDR WG could write a short informational RFC that points to that web page so that whilst the text is not in the RFC series, it can be found from the RFC series of documents. 4) The IDR WG could request that the authors approach the Independent Stream RFC Editor, and ask that this draft be published as a RFC in the Independent Stream. Publication in the independent stream would require a conflict review, but if the consensus of the WG was to use this approach, I foresee no issue in that regard. If this approach is taken, I would suggest that the opinion of the IS Editor is sought, before making significant edits to the text of the draft. 5) The IDR WG Chairs could approach another member of the IESG and ask if they would be prepared to sponsor publication of this draft as an RFC. I would not block publication of the draft if it was sponsored by another Area Director. It is of course up to the IDR WG which path it is chosen to explore, but if I were going to progress this draft as a chair, I would probably start by exploring options (3+3a) and (4) in the list above, since this probably requires the least editing of the existing draft text. I am therefore returning this draft to the IDR working group, and await the decision of the IDR Chairs on how they wish to proceed. Regards Stewart ------=_NextPart_000_01D9_01CDAC65.1E73C3B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart:

 

We will approach item 4 and 3 and 3a in parallel.  Thank you for = the AD Review.

 

Sue

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: = Wednesday, October 03, 2012 8:02 AM
To: = idr-chairs@tools.ietf.org; idr mailing list; = draft-ietf-idr-bgp-issues@tools.ietf.org
Cc: = iesg@ietf.org
Subject: AD statement on = draft-ietf-idr-bgp-issues

 

 
T=
o the IDR WG, IDR WG Chairs and authors of =

draft-ietf-idr-bgp-issues:
 
I have performed an Area Director review of =

draft-ietf-idr-bgp-issues (Issues in Revising =
BGP-4 
(RFC1771 to RFC4271)), and it is my =
conclusion that,
as submitted to me for AD review, =
this draft is not
suitable for publication as an =
RFC in the IETF =

Series.
 
Whilst I understand and support the goal of =

documenting the key design decisions that =
formed
the basis of the BGP RFC4271, the =
method
that the authors have chosen to present this =

information lacks the efficiency of presentation =

of information that I believe is required in the =

IETF RFC =
Series.
 
The draft is a =
reproduction of detailed email
exchanges that took =
place on the IDR list in the
early part of the last =
decade, together with a 
running commentary and =
conclusion on each
point. Within this 170 pages of =
text there
is far too much cruft and irrelevant =
discussion
for me to accept this publication =
request. 
 
As an aside I =
also have serious concerns at the 
extent of review =
that this document has received 
by the IDR WG. The =
only commenter during WG Last 
call states =
"... I did look at it when it first 
appeared, =
in 2005,  and put it on the shelf 
for further =
study, where it has remained 
ever since." =
This in itself gives concerns 
regarding the method =
that the authors have 
chosen to present this =
information to the =
reader.
 
I therefore =
think that IDR WG needs to find 
another way to =
record this information for 
posterity in a =
archival format.
 
The =
IDR WG could proceed on a number of paths with
this =
work. I suggest six ways forward here, but
others =
may be also =
acceptable.
 
1) The IDR =
WG could heavily edit the draft 
so that it =
presents in a more conventional, 
significantly =
shorter format, the essential 
issues that were =
resolved and baked into RFC4271.
I would sponsor =
the publication of a significantly
reduced, well =
targeted, =
document.
 
 2) The =
IDR WG could deconstruct the issues and 
record =
them in the IETF issue tracker software.
This is a =
method that other WGs have used to address
this =
problem. I accept that this was not possible
when =
the draft was first written in 2003, and that
this =
approach would be a great deal of work. We
would =
have to verify the degree to which this
approach =
matched the archival requirements of the 
IDR WG. =

 
 3) The IDR WG =
could make some minor modifications and
publish =
this text on an IETF web page with a 
permanent =
URL.
 
 3a) The IDR =
WG could write a short informational RFC =
that
points to that web page so that whilst the =
text is
not in the RFC series, it can be found from =
the RFC
series of =
documents.
 
4) The IDR =
WG could request that the authors approach 
the =
Independent Stream RFC Editor, and ask that 
this =
draft be published as a RFC in the Independent =

Stream. Publication in the independent stream =
would 
require a conflict review, but if the =
consensus of 
the WG was to use this approach, I =
foresee no 
issue in that regard. If this approach =
is taken,
I would suggest that the opinion of the =
IS Editor
is sought, before making significant =
edits to the 
text of the =
draft.
 
5) The IDR WG =
Chairs could approach another member 
of the IESG =
and ask if they would be prepared to 
sponsor =
publication of this draft as an RFC. I
would not =
block publication of the draft if it 
was sponsored =
by another Area =
Director.
 
It is of =
course up to the IDR WG which
path it is chosen to =
explore, but if I were
going to progress this draft =
as a chair, I would
probably start by exploring =
options (3+3a) and (4) 
in the list above, since =
this probably requires 
the least editing of the =
existing draft text.
 
I =
am therefore returning this draft to the =
IDR
working group, and await the decision of the =

IDR Chairs on how they wish to =
proceed.
 
Regards
 
Stewart =

 
 
=

 
 
 <=
/o:p>
 
 
= ------=_NextPart_000_01D9_01CDAC65.1E73C3B0-- From pmehta@cisco.com Wed Oct 17 10:25:24 2012 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 68EC421F8645; Wed, 17 Oct 2012 10:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oki0vouPQlj8; Wed, 17 Oct 2012 10:25:19 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5851221F8630; Wed, 17 Oct 2012 10:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2221; q=dns/txt; s=iport; t=1350494719; x=1351704319; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fflUiMzSCMRzVB45qbPibM3RNu4QFH79EC5N/d8EU34=; b=fNo8UECYd7weRHo6PYTzwcOdluGkyF10dmJYOoFhE/Hx8gL1N3+DOsUG j85iW7ug0rzMVboB44UU5g20nWMMFq5Aqe9QM2c7C73igXMi5t+D0htnx rnxQqd2WTun5C/b4MZ8A6LiUrfwo1bH3AOKedqZ0hkhDnkEYLi3Kuk1lK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPboflCtJV2c/2dsb2JhbABFwCCBCIIgAQEBBBIBJz8MBAIBCBEEAQELFAkHIREUCQgCBA4FCBMHh1ADDgGbPJZMDYlUinBoJ4U7YAOUFox5gyWBa4JvgVwjGA X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="132670652" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 17 Oct 2012 17:25:18 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9HHPIUH026178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 17:25:19 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.63]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 12:25:18 -0500 From: "Pranav Mehta (pmehta)" To: Robert Raszuk Thread-Topic: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Index: AQHNqwAew0fd+6zQc0WX8IHgfJLNm5e7mp+AgAADjgCAAAYMgIAAAbKAgAC9qHCAAN9DAIAAf3Xw Date: Wed, 17 Oct 2012 17:25:18 +0000 Message-ID: <80F8B5888DDE96498217BE8A5C47436F180EF8@xmb-rcd-x13.cisco.com> References: <20121015175711.5993.31704.idtracker@ietfa.amsl.com> <80F8B5888DDE96498217BE8A5C47436F17F611@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.138.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--37.547400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Keyur Patel \(keyupate\)" , L3VPN , idr wg , "luay.jalil@verizon.com" Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:25:24 -0000 Hi Robert, Thanks for your feedback. My comments inline.. #P# -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Tuesday, October 16, 2012 9:47 PM To: Pranav Mehta (pmehta) Cc: Randy Bush; Keyur Patel (keyupate); Arjun Sreekantiah (asreekan); luay.= jalil@verizon.com; idr wg; L3VPN Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt Hey Pranav, Do you really believe that each 7-11 or Walmart store will be subscribing t= o global RPKI or building their own key infrastructure? I do not. It seems = few orders of magnitude easier to sign advertisements at the src/spoke and = validate signature at the hub site by the same very network admin residing = in the enterprise hub location. That is something we should define in BGP f= or VPNs and not trying to reuse origin validation concept which works well = (for what it is designed to do) in the Internet case. #P# I don't think 7-11/Walmart will be subscribing to global RPKI or even b= uild their own infrastructure. RPKI makes it easier to distribute the key = but the end CE can be configured to use a static Key and this draft doesn't= preclude provisioning using static configuration. As far as all the sites= belong to same network admin, same key can be provisioned on all the sites= and in such case we don't need to get RPKI infrastructure involved. If it= 's not clear from the draft, we can definitely change the wording to clarif= y this. Btw ,,, I do not buy any "trusted" ASBR business ;) #P# In most of the cases I agree that this asymmetric solution might not be pre= ferred but think about a scenario where a VPN has few sites connected via n= on-trusted provided and most of the other (may be in thousands) sites are c= onnected to a trusted provider. Instead of upgrading all these sites to ge= nerated signed NLRIs the VPN can choose to just add the authentication at t= he ASBR boundary to protect prefix origination from un-trusted network. Th= e goal of this draft is to allow the flexibility by adding Key Identifier s= o that VPN is not forced to upgrade all the sites under this scenario. =20 Thanks, -- Pranav From robert@raszuk.net Wed Oct 17 19:50:15 2012 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 CEED921F8518 for ; Wed, 17 Oct 2012 19:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB4dO77mjV3T for ; Wed, 17 Oct 2012 19:50:15 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF6521F8513 for ; Wed, 17 Oct 2012 19:50:13 -0700 (PDT) Received: (qmail 17169 invoked by uid 399); 18 Oct 2012 02:51:18 -0000 Received: from unknown (HELO ?192.168.50.166?) (pbs:robert@raszuk.net@70.164.119.40) by mail1310.opentransfer.com with ESMTPM; 18 Oct 2012 02:51:18 -0000 X-Originating-IP: 70.164.119.40 To: "=?utf-8?B?UHJhbmF2IE1laHRhLCAocG1laHRhKQ==?=" From: "=?utf-8?B?cm9iZXJ0QHJhc3p1ay5uZXQ=?=" Date: Wed, 17 Oct 2012 19:50:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1350528612140" Message-Id: <20121018025013.9BF6521F8513@ietfa.amsl.com> Cc: =?utf-8?B?S2V5dXIgUGF0ZWwsIChrZXl1cGF0ZSk=?= , L3VPN , =?utf-8?B?aWRyIHdn?= , =?utf-8?B?bHVheS5qYWxpbEB2ZXJpem9uLmNvbQ==?= Subject: Re: [Idr] =?utf-8?q?draft-ymbk-l3vpn-origination-00=2Etxt?= 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, 18 Oct 2012 02:50:15 -0000 ------=_Part_0_1350528612140 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgUHJhbmF2LCAgCgpIZWxwIG1lIHVuZGVyc3RhbmQgaGVyZSB0aGF0IGlmIHdlIGFyZSB0YWxr aW5nIGFib3V0IHN0YXRpY2FsbHkgY29uZmlndXJlZCBrZXkgb24gdGhlIENFcyB3b3VsZCBpdCBi ZSBub3QgYmV0dGVyIHRvIGNvbnNpZGVyIGUtc2lnbmF0dXJlIGZyb20gdmVyaXNpZ24gaW5zdGVh ZCA/CgpUaHgsClIuCgotLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tCkZyb206ICJQcmFuYXYgTWVo dGEgKHBtZWh0YSkiIDxwbWVodGFAY2lzY28uY29tPgpUbzogIlJvYmVydCBSYXN6dWsiIDxyb2Jl cnRAcmFzenVrLm5ldD4KQ2M6ICJSYW5keSBCdXNoIiA8cmFuZHlAcHNnLmNvbT4sICJLZXl1ciBQ YXRlbCAoa2V5dXBhdGUpIiA8a2V5dXBhdGVAY2lzY28uY29tPiwgIkFyanVuIFNyZWVrYW50aWFo IChhc3JlZWthbikiIDxhc3JlZWthbkBjaXNjby5jb20+LCAibHVheS5qYWxpbEB2ZXJpem9uLmNv bSIgPGx1YXkuamFsaWxAdmVyaXpvbi5jb20+LCAiaWRyIHdnIiA8aWRyQGlldGYub3JnPiwgIkwz VlBOIiA8bDN2cG5AaWV0Zi5vcmc+ClN1YmplY3Q6IFtJZHJdIGRyYWZ0LXltYmstbDN2cG4tb3Jp Z2luYXRpb24tMDAudHh0CkRhdGU6IFdlZCwgT2N0IDE3LCAyMDEyIDEwOjI1CgoKSGkgUm9iZXJ0 LAoKVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLiAgTXkgY29tbWVudHMgaW5saW5lLi4gI1AjCgot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRv OnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1awpTZW50OiBUdWVz ZGF5LCBPY3RvYmVyIDE2LCAyMDEyIDk6NDcgUE0KVG86IFByYW5hdiBNZWh0YSAocG1laHRhKQpD YzogUmFuZHkgQnVzaDsgS2V5dXIgUGF0ZWwgKGtleXVwYXRlKTsgQXJqdW4gU3JlZWthbnRpYWgg KGFzcmVla2FuKTsgbHVheS5qYWxpbEB2ZXJpem9uLmNvbTsgaWRyIHdnOyBMM1ZQTgpTdWJqZWN0 OiBSZTogW0lkcl0gZHJhZnQteW1iay1sM3Zwbi1vcmlnaW5hdGlvbi0wMC50eHQKCkhleSBQcmFu YXYsCgpEbyB5b3UgcmVhbGx5IGJlbGlldmUgdGhhdCBlYWNoIDctMTEgb3IgV2FsbWFydCBzdG9y ZSB3aWxsIGJlIHN1YnNjcmliaW5nIHRvIGdsb2JhbCBSUEtJIG9yIGJ1aWxkaW5nIHRoZWlyIG93 biBrZXkgaW5mcmFzdHJ1Y3R1cmU/IEkgZG8gbm90LiBJdCBzZWVtcyBmZXcgb3JkZXJzIG9mIG1h Z25pdHVkZSBlYXNpZXIgdG8gc2lnbiBhZHZlcnRpc2VtZW50cyBhdCB0aGUgc3JjL3Nwb2tlIGFu ZCB2YWxpZGF0ZSBzaWduYXR1cmUgYXQgdGhlIGh1YiBzaXRlIGJ5IHRoZSBzYW1lIHZlcnkgbmV0 d29yayBhZG1pbiByZXNpZGluZyBpbiB0aGUgZW50ZXJwcmlzZSBodWIgbG9jYXRpb24uIFRoYXQg aXMgc29tZXRoaW5nIHdlIHNob3VsZCBkZWZpbmUgaW4gQkdQIGZvciBWUE5zIGFuZCBub3QgdHJ5 aW5nIHRvIHJldXNlIG9yaWdpbiB2YWxpZGF0aW9uIGNvbmNlcHQgd2hpY2ggd29ya3Mgd2VsbCAo Zm9yIHdoYXQgaXQgaXMgZGVzaWduZWQgdG8KZG8pIGluIHRoZSBJbnRlcm5ldCBjYXNlLgoKI1Aj IEkgZG9uJ3QgdGhpbmsgNy0xMS9XYWxtYXJ0IHdpbGwgYmUgc3Vic2NyaWJpbmcgdG8gZ2xvYmFs IFJQS0kgb3IgZXZlbiBidWlsZCB0aGVpciBvd24gaW5mcmFzdHJ1Y3R1cmUuICBSUEtJIG1ha2Vz IGl0IGVhc2llciB0byBkaXN0cmlidXRlIHRoZSBrZXkgYnV0IHRoZSBlbmQgQ0UgY2FuIGJlIGNv bmZpZ3VyZWQgdG8gdXNlIGEgc3RhdGljIEtleSBhbmQgdGhpcyBkcmFmdCBkb2Vzbid0IHByZWNs dWRlIHByb3Zpc2lvbmluZyB1c2luZyBzdGF0aWMgY29uZmlndXJhdGlvbi4gIEFzIGZhciBhcyBh bGwgdGhlIHNpdGVzIGJlbG9uZyB0byBzYW1lIG5ldHdvcmsgYWRtaW4sIHNhbWUga2V5IGNhbiBi ZSBwcm92aXNpb25lZCBvbiBhbGwgdGhlIHNpdGVzIGFuZCBpbiBzdWNoIGNhc2Ugd2UgZG9uJ3Qg bmVlZCB0byBnZXQgUlBLSSBpbmZyYXN0cnVjdHVyZSBpbnZvbHZlZC4gIElmIGl0J3Mgbm90IGNs ZWFyIGZyb20gdGhlIGRyYWZ0LCB3ZSBjYW4gZGVmaW5pdGVseSBjaGFuZ2UgdGhlIHdvcmRpbmcg dG8gY2xhcmlmeSB0aGlzLgoKQnR3ICwsLCBJIGRvIG5vdCBidXkgYW55ICJ0cnVzdGVkIiBBU0JS IGJ1c2luZXNzIDspCgojUCMKSW4gbW9zdCBvZiB0aGUgY2FzZXMgSSBhZ3JlZSB0aGF0IHRoaXMg YXN5bW1ldHJpYyBzb2x1dGlvbiBtaWdodCBub3QgYmUgcHJlZmVycmVkIGJ1dCB0aGluayBhYm91 dCBhIHNjZW5hcmlvIHdoZXJlIGEgVlBOIGhhcyBmZXcgc2l0ZXMgY29ubmVjdGVkIHZpYSBub24t dHJ1c3RlZCBwcm92aWRlZCBhbmQgbW9zdCBvZiB0aGUgb3RoZXIgKG1heSBiZSBpbiB0aG91c2Fu ZHMpIHNpdGVzIGFyZSBjb25uZWN0ZWQgdG8gYSB0cnVzdGVkIHByb3ZpZGVyLiAgSW5zdGVhZCBv ZiB1cGdyYWRpbmcgYWxsIHRoZXNlIHNpdGVzIHRvIGdlbmVyYXRlZCBzaWduZWQgTkxSSXMgdGhl IFZQTiBjYW4gY2hvb3NlIHRvIGp1c3QgYWRkIHRoZSBhdXRoZW50aWNhdGlvbiBhdCB0aGUgQVNC UiBib3VuZGFyeSB0byBwcm90ZWN0IHByZWZpeCBvcmlnaW5hdGlvbiBmcm9tIHVuLXRydXN0ZWQg bmV0d29yay4gIFRoZSBnb2FsIG9mIHRoaXMgZHJhZnQgaXMgdG8gYWxsb3cgdGhlIGZsZXhpYmls aXR5IGJ5IGFkZGluZyBLZXkgSWRlbnRpZmllciBzbyB0aGF0IFZQTiBpcyBub3QgZm9yY2VkIHRv IHVwZ3JhZGUgYWxsIHRoZSBzaXRlcyB1bmRlciB0aGlzIHNjZW5hcmlvLiAgCgoKVGhhbmtzLAot LSBQcmFuYXYK ------=_Part_0_1350528612140 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgUHJhbmF2LCAmbmJzcDs8YnI+PGJyPkhlbHAgbWUgdW5kZXJzdGFuZCBoZXJlIHRoYXQgaWYg d2UgYXJlIHRhbGtpbmcgYWJvdXQgc3RhdGljYWxseSBjb25maWd1cmVkIGtleSBvbiB0aGUgQ0Vz IHdvdWxkIGl0IGJlIG5vdCBiZXR0ZXIgdG8gY29uc2lkZXIgZS1zaWduYXR1cmUgZnJvbSB2ZXJp c2lnbiBpbnN0ZWFkID88YnI+PGJyPlRoeCw8YnI+Ui48YnI+PGJyPi0tLS0tIFJlcGx5IG1lc3Nh Z2UgLS0tLS08YnI+RnJvbTogJnF1b3Q7UHJhbmF2IE1laHRhIChwbWVodGEpJnF1b3Q7ICZsdDtw bWVodGFAY2lzY28uY29tJmd0Ozxicj5UbzogJnF1b3Q7Um9iZXJ0IFJhc3p1ayZxdW90OyAmbHQ7 cm9iZXJ0QHJhc3p1ay5uZXQmZ3Q7PGJyPkNjOiAmcXVvdDtSYW5keSBCdXNoJnF1b3Q7ICZsdDty YW5keUBwc2cuY29tJmd0OywgJnF1b3Q7S2V5dXIgUGF0ZWwgKGtleXVwYXRlKSZxdW90OyAmbHQ7 a2V5dXBhdGVAY2lzY28uY29tJmd0OywgJnF1b3Q7QXJqdW4gU3JlZWthbnRpYWggKGFzcmVla2Fu KSZxdW90OyAmbHQ7YXNyZWVrYW5AY2lzY28uY29tJmd0OywgJnF1b3Q7bHVheS5qYWxpbEB2ZXJp em9uLmNvbSZxdW90OyAmbHQ7bHVheS5qYWxpbEB2ZXJpem9uLmNvbSZndDssICZxdW90O2lkciB3 ZyZxdW90OyAmbHQ7aWRyQGlldGYub3JnJmd0OywgJnF1b3Q7TDNWUE4mcXVvdDsgJmx0O2wzdnBu QGlldGYub3JnJmd0Ozxicj5TdWJqZWN0OiBbSWRyXSBkcmFmdC15bWJrLWwzdnBuLW9yaWdpbmF0 aW9uLTAwLnR4dDxicj5EYXRlOiBXZWQsIE9jdCAxNywgMjAxMiAxMDoyNTxicj48YnI+PGJyPkhp IFJvYmVydCw8YnI+PGJyPlRoYW5rcyBmb3IgeW91ciBmZWVkYmFjay4gJm5ic3A7TXkgY29tbWVu dHMgaW5saW5lLi4gI1AjPGJyPjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj5Gcm9t OiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYg T2YgUm9iZXJ0IFJhc3p1azxicj5TZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE2LCAyMDEyIDk6NDcg UE08YnI+VG86IFByYW5hdiBNZWh0YSAocG1laHRhKTxicj5DYzogUmFuZHkgQnVzaDsgS2V5dXIg UGF0ZWwgKGtleXVwYXRlKTsgQXJqdW4gU3JlZWthbnRpYWggKGFzcmVla2FuKTsgbHVheS5qYWxp bEB2ZXJpem9uLmNvbTsgaWRyIHdnOyBMM1ZQTjxicj5TdWJqZWN0OiBSZTogW0lkcl0gZHJhZnQt eW1iay1sM3Zwbi1vcmlnaW5hdGlvbi0wMC50eHQ8YnI+PGJyPkhleSBQcmFuYXYsPGJyPjxicj5E byB5b3UgcmVhbGx5IGJlbGlldmUgdGhhdCBlYWNoIDctMTEgb3IgV2FsbWFydCBzdG9yZSB3aWxs IGJlIHN1YnNjcmliaW5nIHRvIGdsb2JhbCBSUEtJIG9yIGJ1aWxkaW5nIHRoZWlyIG93biBrZXkg aW5mcmFzdHJ1Y3R1cmU/IEkgZG8gbm90LiBJdCBzZWVtcyBmZXcgb3JkZXJzIG9mIG1hZ25pdHVk ZSBlYXNpZXIgdG8gc2lnbiBhZHZlcnRpc2VtZW50cyBhdCB0aGUgc3JjL3Nwb2tlIGFuZCB2YWxp ZGF0ZSBzaWduYXR1cmUgYXQgdGhlIGh1YiBzaXRlIGJ5IHRoZSBzYW1lIHZlcnkgbmV0d29yayBh ZG1pbiByZXNpZGluZyBpbiB0aGUgZW50ZXJwcmlzZSBodWIgbG9jYXRpb24uIFRoYXQgaXMgc29t ZXRoaW5nIHdlIHNob3VsZCBkZWZpbmUgaW4gQkdQIGZvciBWUE5zIGFuZCBub3QgdHJ5aW5nIHRv IHJldXNlIG9yaWdpbiB2YWxpZGF0aW9uIGNvbmNlcHQgd2hpY2ggd29ya3Mgd2VsbCAoZm9yIHdo YXQgaXQgaXMgZGVzaWduZWQgdG88YnI+ZG8pIGluIHRoZSBJbnRlcm5ldCBjYXNlLjxicj48YnI+ I1AjIEkgZG9uJiMzOTt0IHRoaW5rIDctMTEvV2FsbWFydCB3aWxsIGJlIHN1YnNjcmliaW5nIHRv IGdsb2JhbCBSUEtJIG9yIGV2ZW4gYnVpbGQgdGhlaXIgb3duIGluZnJhc3RydWN0dXJlLiAmbmJz cDtSUEtJIG1ha2VzIGl0IGVhc2llciB0byBkaXN0cmlidXRlIHRoZSBrZXkgYnV0IHRoZSBlbmQg Q0UgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gdXNlIGEgc3RhdGljIEtleSBhbmQgdGhpcyBkcmFmdCBk b2VzbiYjMzk7dCBwcmVjbHVkZSBwcm92aXNpb25pbmcgdXNpbmcgc3RhdGljIGNvbmZpZ3VyYXRp b24uICZuYnNwO0FzIGZhciBhcyBhbGwgdGhlIHNpdGVzIGJlbG9uZyB0byBzYW1lIG5ldHdvcmsg YWRtaW4sIHNhbWUga2V5IGNhbiBiZSBwcm92aXNpb25lZCBvbiBhbGwgdGhlIHNpdGVzIGFuZCBp biBzdWNoIGNhc2Ugd2UgZG9uJiMzOTt0IG5lZWQgdG8gZ2V0IFJQS0kgaW5mcmFzdHJ1Y3R1cmUg aW52b2x2ZWQuICZuYnNwO0lmIGl0JiMzOTtzIG5vdCBjbGVhciBmcm9tIHRoZSBkcmFmdCwgd2Ug Y2FuIGRlZmluaXRlbHkgY2hhbmdlIHRoZSB3b3JkaW5nIHRvIGNsYXJpZnkgdGhpcy48YnI+PGJy PkJ0dyAsLCwgSSBkbyBub3QgYnV5IGFueSAmcXVvdDt0cnVzdGVkJnF1b3Q7IEFTQlIgYnVzaW5l c3MgOyk8YnI+PGJyPiNQIzxicj5JbiBtb3N0IG9mIHRoZSBjYXNlcyBJIGFncmVlIHRoYXQgdGhp cyBhc3ltbWV0cmljIHNvbHV0aW9uIG1pZ2h0IG5vdCBiZSBwcmVmZXJyZWQgYnV0IHRoaW5rIGFi b3V0IGEgc2NlbmFyaW8gd2hlcmUgYSBWUE4gaGFzIGZldyBzaXRlcyBjb25uZWN0ZWQgdmlhIG5v bi10cnVzdGVkIHByb3ZpZGVkIGFuZCBtb3N0IG9mIHRoZSBvdGhlciAobWF5IGJlIGluIHRob3Vz YW5kcykgc2l0ZXMgYXJlIGNvbm5lY3RlZCB0byBhIHRydXN0ZWQgcHJvdmlkZXIuICZuYnNwO0lu c3RlYWQgb2YgdXBncmFkaW5nIGFsbCB0aGVzZSBzaXRlcyB0byBnZW5lcmF0ZWQgc2lnbmVkIE5M UklzIHRoZSBWUE4gY2FuIGNob29zZSB0byBqdXN0IGFkZCB0aGUgYXV0aGVudGljYXRpb24gYXQg dGhlIEFTQlIgYm91bmRhcnkgdG8gcHJvdGVjdCBwcmVmaXggb3JpZ2luYXRpb24gZnJvbSB1bi10 cnVzdGVkIG5ldHdvcmsuICZuYnNwO1RoZSBnb2FsIG9mIHRoaXMgZHJhZnQgaXMgdG8gYWxsb3cg dGhlIGZsZXhpYmlsaXR5IGJ5IGFkZGluZyBLZXkgSWRlbnRpZmllciBzbyB0aGF0IFZQTiBpcyBu b3QgZm9yY2VkIHRvIHVwZ3JhZGUgYWxsIHRoZSBzaXRlcyB1bmRlciB0aGlzIHNjZW5hcmlvLiAm bmJzcDs8YnI+PGJyPjxicj5UaGFua3MsPGJyPi0tIFByYW5hdjxicj4= ------=_Part_0_1350528612140-- From randy@psg.com Wed Oct 17 19:52:07 2012 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 7A35021F8523; Wed, 17 Oct 2012 19:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bQwmOkfeNJr; Wed, 17 Oct 2012 19:52:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1A721F851B; Wed, 17 Oct 2012 19:52:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TOgDK-000Opn-DI; Thu, 18 Oct 2012 02:52:02 +0000 Date: Wed, 17 Oct 2012 16:52:01 -1000 Message-ID: From: Randy Bush To: "robert@raszuk.net" User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , L3VPN , "luay.jalil@verizon.com" , "Keyur Patel, \(keyupate\)" Subject: Re: [Idr] draft-ymbk-l3vpn-origination-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: Thu, 18 Oct 2012 02:52:07 -0000 > Help me understand here that if we are talking about statically > configured key on the CEs would it be not better to consider > e-signature from verisign instead ? the keys are arbitrary. you can get ecerts from macdonalds for all the spec cares. randy From robert@raszuk.net Wed Oct 17 20:15:43 2012 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 BEBF111E809C for ; Wed, 17 Oct 2012 20:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.195 X-Spam-Level: X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=0.804, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cq8xm3KVygQ for ; Wed, 17 Oct 2012 20:15:43 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 149B711E8099 for ; Wed, 17 Oct 2012 20:15:43 -0700 (PDT) Received: (qmail 17978 invoked by uid 399); 18 Oct 2012 03:16:47 -0000 Received: from unknown (HELO ?192.168.51.101?) (pbs:robert@raszuk.net@70.164.119.40) by mail1310.opentransfer.com with ESMTPM; 18 Oct 2012 03:16:47 -0000 X-Originating-IP: 70.164.119.40 Message-ID: <507F745C.6000508@raszuk.net> Date: Thu, 18 Oct 2012 05:15:40 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr wg , L3VPN , "luay.jalil@verizon.com" Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.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, 18 Oct 2012 03:15:43 -0000 > the keys are arbitrary. you can get ecerts from macdonalds for all > the spec cares. If this is so what is so novel about your draft if compared with already existing for over 10 years L3VPN WG below document ? http://tools.ietf.org/html/draft-ietf-l3vpn-auth-00 ? Thx, R. >> Help me understand here that if we are talking about statically >> configured key on the CEs would it be not better to consider >> e-signature from verisign instead ? > > the keys are arbitrary. you can get ecerts from macdonalds for all the > spec cares. > > randy > > From ietfc@btconnect.com Thu Oct 18 02:40:25 2012 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 92A1F21F8523 for ; Thu, 18 Oct 2012 02:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2MITSBearLF for ; Thu, 18 Oct 2012 02:40:20 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 687A821F8501 for ; Thu, 18 Oct 2012 02:40:20 -0700 (PDT) Received: from mail45-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Thu, 18 Oct 2012 09:40:18 +0000 Received: from mail45-ch1 (localhost [127.0.0.1]) by mail45-ch1-R.bigfish.com (Postfix) with ESMTP id C8AC74800A3; Thu, 18 Oct 2012 09:40:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371I542M1432I1418Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh172cdfhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h304l1155h1493h) Received: from mail45-ch1 (localhost.localdomain [127.0.0.1]) by mail45-ch1 (MessageSwitch) id 1350553217423123_23950; Thu, 18 Oct 2012 09:40:17 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail45-ch1.bigfish.com (Postfix) with ESMTP id 64CC61C0043; Thu, 18 Oct 2012 09:40:17 +0000 (UTC) Received: from AMSPRD0710HT001.eurprd07.prod.outlook.com (157.56.249.85) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 18 Oct 2012 09:40:16 +0000 Received: from AMSPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.5) by pod51017.outlook.com (10.255.160.164) with Microsoft SMTP Server (TLS) id 14.16.224.5; Thu, 18 Oct 2012 09:40:14 +0000 Message-ID: <019f01cdad14$8b53f9a0$4001a8c0@gateway.2wire.net> From: t.petch To: , , , References: <20120926090655.84AD3B1E002@rfc-editor.org> <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> <1517926197-1350505309-cardhu_decombobulator_blackberry.rim.net-592115365-@b27.c6.bise6.blackberry> Date: Thu, 18 Oct 2012 10:39:08 +0100 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-Originating-IP: [157.56.248.5] X-FOPE-CRA-Verdict: 157.56.249.85$juniper.net%12218%4%btconnect.com%False%False%0$ X-OriginatorOrg: btconnect.com Cc: shtyagi@microsoft.com, "idr@ietf. org" Subject: Re: [Idr] Spam:*******, Re: [Technical Errata Reported] RFC4271 (3366) 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, 18 Oct 2012 09:40:25 -0000 ----- Original Message ----- From: To: "t petch" ; ; ; ; ; "RFC Editor" Cc: ; "idr@ietf. org" Sent: Wednesday, October 17, 2012 9:21 PM > Tom: > > Thank you for all your comments on the state machine. Do you want all my comments on the list or off-list with summaries of our discussion on the list. > > You can infer from this message that I disagree with you on your state machine comments. Sue, Um, that sounds ominous:-( but I think it best if the comments are on-list. As you probably realise, the thoughts I expressed below were my first thoughts and were in error in, e.g., saying that a KEEPALIVE had been sent when it had not. My last thoughts, to date, were those of October 5th. Tom Petch > Sue > Sent via BlackBerry by AT&T > > -----Original Message----- > From: t.petch > Date: Tue, 2 Oct 2012 14:41:36 > To: ; ; ; ; ; ; ; RFC Errata System > Cc: ; ; > Subject: Spam:*******, Re: [Idr] [Technical Errata Reported] RFC4271 (3366) > > From the Original Text, I infer that this refers to OpenSent, when event > 18 occurs. > > The Notes say > > "HoldTimer should only be used to control time in between BGP packets. " > > This is true but in OpenSent state (p.63), a KEEPALIVE has been sent (as > well as an OPEN) so the timer should be running. > > "Also in this case it can lead to case in ACTIVE state where HoldTimer > expires before the ConnectRetryTimer leading to IDLE state." > > Well, it will lead to Active state (p.59) - that is what the text says - > and event 10, HoldTimer expires, will then take you to Idle state > (p.63). > > The expectation is that the HoldTimer has been set to a large value, 4 > minutes, which is much greater than the ConnectRetryTimer (90s) and it > is the expiry of the latter that should take you out of Active state to > Connect and thence to OpenSent when the HoldTimer will be restarted. > Note that the receipt of a KEEPALIVE (event 26) also takes you from > Active to Idle - I think that the two cases are similar, that the BGP > connection did not reach second base. You are in trouble either way and > back to Idle is the safe thing to do. > > Of course, if you ignore that advice to set the HoldTimer to a large > value - you have yet to receive an OPEN and so do not know what value > will be acceptable to the peer - and set it instead to 3s, then yes, you > will get back to Idle more often than is desirable. > > Nowadays, there is a greater wish to keep BGP connections up, compared > to when we wrote RFC4271, but I think that, in this case, there is > nothing worth keeping up and going back to Idle is the right thing to > do. > > (I am not sure what the best distribution for this is so I have used > 'Reply All' but expect that that should be trimmed soon). > > Tom Petch > > > ----- Original Message ----- > From: "RFC Errata System" > To: ; ; ; > ; ; ; > > Cc: ; ; > Sent: Wednesday, September 26, 2012 10:06 AM > Subject: [Idr] [Technical Errata Reported] RFC4271 (3366) > > > > > > The following errata report has been submitted for RFC4271, > > "A Border Gateway Protocol 4 (BGP-4)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3366 > > > > -------------------------------------- > > Type: Technical > > Reported by: Shashank Tyagi > > > > Section: 8.2.2 > > > > Original Text > > ------------- > > If a TcpConnectionFails event (Event 18) is received, the local > > system: > > > > - closes the BGP connection, > > > > - restarts the ConnectRetryTimer, > > > > - continues to listen for a connection that may be initiated > by > > the remote BGP peer, and > > > > - changes its state to Active. > > > > Corrected Text > > -------------- > > If a TcpConnectionFails event (Event 18) is received, the local > > system: > > > > - closes the BGP connection, > > > > - sets the HoldTimer to 0, > > > > - restarts the ConnectRetryTimer, > > > > - continues to listen for a connection that may be initiated > by > > the remote BGP peer, and > > > > - changes its state to Active. > > > > Notes > > ----- > > HoldTimer should only be used to control time in between BGP packets. > > Also in this case it can lead to case in ACTIVE state where HoldTimer > expires before the ConnectRetryTimer leading to IDLE state. > > > > 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. > > > > -------------------------------------- > > RFC4271 (draft-ietf-idr-bgp4-26) > > -------------------------------------- > > Title : A Border Gateway Protocol 4 (BGP-4) > > Publication Date : January 2006 > > Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. > > Category : DRAFT STANDARD > > Source : Inter-Domain Routing > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > > > > > From internet-drafts@ietf.org Sat Oct 20 19:49:40 2012 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 AE8AD21F8680; Sat, 20 Oct 2012 19:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJbAGvsmZCWK; Sat, 20 Oct 2012 19:49:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430F421F8630; Sat, 20 Oct 2012 19:49:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121021024940.7697.10005.idtracker@ietfa.amsl.com> Date: Sat, 20 Oct 2012 19:49:40 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as4octet-extcomm-generic-subtype-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: Sun, 21 Oct 2012 02:49:40 -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 : Generic Subtype for BGP Four-octet AS specific extended = community Author(s) : Dhananjaya Rao Pradosh Mohapatra Jeffrey Haas Filename : draft-ietf-idr-as4octet-extcomm-generic-subtype-06.txt Pages : 6 Date : 2012-10-20 Abstract: Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific BGP extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as4octet-extcomm-generic-su= btype There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-= 06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-as4octet-extcomm-generic-= subtype-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rraszuk@gmail.com Sun Oct 21 07:33:31 2012 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 488D121F8596; Sun, 21 Oct 2012 07:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH2-X+Nl6s1H; Sun, 21 Oct 2012 07:33:30 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7BB21F844B; Sun, 21 Oct 2012 07:33:27 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so1728732iad.31 for ; Sun, 21 Oct 2012 07:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hI9ixZCLsIX/gMnx9tuiq/uqm5guzw0vnwPNmsuuINY=; b=wP4YNBXW5zA1IjJxmKaBVpqsTRJ9URg+ZFMJCRKbRCoDEmkkIR+PP2KhIaJespxKpy 38fX4nrxxT86WvzxTQG0uAbdzfrjGOi1HYGi3d1hO4MZyk9gyRjHab95OWrUOOHTWLLb pZgc/J3bPF6HV4WeavRJwlLIpE9Wfy277e2cOoqjKj77ngQ9hXXXc7JGUskLCQFry2BQ DuyqDv8YtiY6Y5omarlHImWqOE2i0qldr17fDb5JPk8xMux92t8yIAdk3Trwd72STjf4 XlyKAZ0IhyLVJRLjMVu7gjd+IWomJbK97zNal/uF5iGVgfL9Q1A9/sq2x8tN2D2LI8OE NPmA== MIME-Version: 1.0 Received: by 10.50.188.225 with SMTP id gd1mr13920584igc.15.1350830007121; Sun, 21 Oct 2012 07:33:27 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Sun, 21 Oct 2012 07:33:27 -0700 (PDT) In-Reply-To: <507F745C.6000508@raszuk.net> References: <507F745C.6000508@raszuk.net> Date: Sun, 21 Oct 2012 16:33:27 +0200 X-Google-Sender-Auth: 5ap0VHgCVU8ir1CxHmewTsGC1-M Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , L3VPN , "luay.jalil@verizon.com" Subject: Re: [Idr] draft-ymbk-l3vpn-origination-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: Sun, 21 Oct 2012 14:33:31 -0000 Hello, Just noticed draft-ymbk-l3vpn-origination-01.txt ... Few follow-up questions to new version: 1. Section "5.2. Provider/ASBR Based Validation/Authentication" indicates possible validation at the ASBR. First clearly it is not possible to do that in option C which I think the draft should mention. In option C you could try to describe such validation on EBGP peering VPNvX RRs. Assuming option-B (or option-C on RRs) how do I set validation policy (based on what value and parameter) that only some VPN customer's routes will be subject for validation ? Same for PEs where subset of VPN customers request validation. Or is the draft discussing only option-A ASBRs ? 2. How much the NLRI validation on the ASBR option B or PE helps if RTs could have been mangled on the way and validated or not routes will end up going to wrong VPN sites ? Draft says: "ASBR2 is the trusted provider with whom CE1 has collaborated." How can one validate on ASBRs (or remote PEs) in the CE based key allocation scheme ? What happens if two VPN customers with overlaping IP addresses will choose the same keys on their CEs ? Note that CEs NLRI do not have notion of RDs and that ingress PEs convert IPv4 NLRIs from CE to VPNv4 NLRIs on PEs adding RD. How can the signature be possibly meaningful anywhere else that on the end PE's VRF or in the end site CE ? 3. In case of validating on the PEs or CEs how does one handle extranets ? Is the plan to share my keys with all extranet partners or use different key per each extranet VPN - case of per CE validation ? How would it work for PE based validation ? How would I carry multiples keys if VPN chooses not to share his secret with some of his extranets ? How do you associate a L3OPA to RTs ? Is the assumption in the draft that such validation is to happen in the VPNvX space on during/past the import the VRFs ? 4. How would service provider be able to inject his own prefixes into VPN sites for offering value add services (example VoIP gateway addresses) if customer chooses CE based validation ? 5. How do I propagate the result of ASBR or PE based validation to the VPN site if such (say multihomed) site is connected to SP not via BGP but via an IGP ? Many thx .. R. On Thu, Oct 18, 2012 at 5:15 AM, Robert Raszuk wrote: >> the keys are arbitrary. you can get ecerts from macdonalds for all >> the spec cares. > > If this is so what is so novel about your draft if compared with already > existing for over 10 years L3VPN WG below document ? > > http://tools.ietf.org/html/draft-ietf-l3vpn-auth-00 > > ? > > Thx, > R. From internet-drafts@ietf.org Mon Oct 22 05:48:14 2012 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 05A5A21F8B73; Mon, 22 Oct 2012 05:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kZLS3hvgiIn; Mon, 22 Oct 2012 05:48:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F0721F8B66; Mon, 22 Oct 2012 05:48:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022124813.30836.55008.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 05:48:13 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-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, 22 Oct 2012 12:48:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : North-Bound Distribution of Link-State and TE Informatio= n using BGP Author(s) : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Saikat Ray Filename : draft-ietf-idr-ls-distribution-01.txt Pages : 35 Date : 2012-10-22 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-ls-distribution-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rraszuk@gmail.com Mon Oct 22 15:02:53 2012 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 4BA7F11E80E1; Mon, 22 Oct 2012 15:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x8eFoWE9142; Mon, 22 Oct 2012 15:02:52 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB7D21F84B2; Mon, 22 Oct 2012 15:02:52 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so2904596iad.31 for ; Mon, 22 Oct 2012 15:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fxgkgk/jXsvC5FWi0Xv/GZqXprgcbo33eWkZPNtOUxM=; b=VNbdfSq4YRM3JH9wMfPF6IlK8KcRuD3qVY6aaGXAuX0Y8xMjieQQXaQrC953lkmzaE MXG8InMjf/Mh0cEu1KNR/muMAv8xnGcy31cvS7UD5VloKWpnTa+4r9yVxQKuQ8KID5jg eT2JURyaO7eVijXSgS86+g7vgQuJXpjp8TtijopA6ehzWNzWMyU1VvzELDvAsYGcr41Z yhSvBjea5c+t73HtZ526JTTIyxKQtzmZKeW5OnoQgQWd+2HMRSYoDp46MfhGmfx4yt76 cDq21G6VxGREoH4VH7rWnncvUFRGd6KmtWog7CPzGiwEuIBM4lQJOa5HJuenSq8mPQ/9 7Pdg== MIME-Version: 1.0 Received: by 10.50.208.71 with SMTP id mc7mr18036576igc.47.1350943371835; Mon, 22 Oct 2012 15:02:51 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Mon, 22 Oct 2012 15:02:51 -0700 (PDT) In-Reply-To: <20121022211358.25006.8180.idtracker@ietfa.amsl.com> References: <20121022211358.25006.8180.idtracker@ietfa.amsl.com> Date: Tue, 23 Oct 2012 00:02:51 +0200 X-Google-Sender-Auth: 35S2ueIcE8DBTtXWbA8gQJT6qU8 Message-ID: From: Robert Raszuk To: idr wg , irs-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Kireeti Kompella Subject: [Idr] Fwd: I-D Action: draft-keyupate-bgp-services-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, 22 Oct 2012 22:02:53 -0000 Dear authors, After reading this document I would like to observe that BGP seems to not fit to the proposed application. Not that it is BGP fault, but the service model required for service dissemination and discovery is much better to be based on publish, subscribe, search primitives rather then p2mp data base distribution propagation which is the BGP model. Putting gateways between service providers and service consumers is a nice try to address the end point BGP protocol language barrier, but it does not address the discovery model. While one could argue that services could have attached RTs and RT-Constrain could be used to push filter to only receive what is necessary however current industry have already solved this problem in a much more elegant way by using MAP servers and IF-MAP protocol between producers and consumers. The database behind the MAP server can be build in a very robust way (as compared to today's BGP state of the art). I would recommend for the authors to consider such alternatives and possibly rewrite the proposal to make it fit the needs of this very important class of application which is service discovery. Best regards, R. ---------- Forwarded message ---------- From: Date: Mon, Oct 22, 2012 at 11:13 PM Subject: I-D Action: draft-keyupate-bgp-services-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Service Advertisement using BGP Author(s) : Keyur Patel Jan Medved Rex Fernando Burjiz Pithawala Filename : draft-keyupate-bgp-services-01.txt Pages : 12 Date : 2012-10-22 Abstract: A variety of services, such as NATs, firewalls, or caches, can be embedded in a service provider network or instantiated in data centers attached to the network. This document proposes extensions to BGP that facilitate discovery of such service instances by interested clients and allows dissemination of service information, such as services capabilities or capacities, throughout the network domain. The proposed extensions allow for optimal routing of requests to service instances that can optimally serve them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-keyupate-bgp-services There's also a htmlized version available at: http://tools.ietf.org/html/draft-keyupate-bgp-services-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-keyupate-bgp-services-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From keyupate@cisco.com Mon Oct 22 16:02:09 2012 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 956B221F8A25; Mon, 22 Oct 2012 16:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nti5ApaPWoaa; Mon, 22 Oct 2012 16:02:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4B34521F8980; Mon, 22 Oct 2012 16:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3847; q=dns/txt; s=iport; t=1350946925; x=1352156525; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2RAV22I1G9ey5FDQ9bAdoSkbJcoa6i4JZJxE7WugRr4=; b=CswCfRDgKEHrL1GNp9GAd9+quMIuMzBAY+L7iqu7VtnKtVDJMoHWuDWX QR9sFo+lv3Rynn0G+dTE1ZfQePtJnEp5Gadcmt1NwcE3r5fsk4OimrfgT ToFklg9r0Oor1JPvR71gjVRIknaJJspFG5ldkLSDm/1kmJMXy2FUDL67I k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPvOhVCtJXG9/2dsb2JhbABFwT+BCIIgAQEBBAEBAQ8BJzQLEgEIEQMBAgsCEjcLHQgCBAENBQgBEgeHYgucD6Ani1iEFoF5YAOXCIoVgyKBa4JiDYIY X-IronPort-AV: E=Sophos;i="4.80,632,1344211200"; d="scan'208";a="134274859" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 22 Oct 2012 23:02:00 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9MN20qf032303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 23:02:00 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.239]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 18:02:00 -0500 From: "Keyur Patel (keyupate)" To: Robert Raszuk , idr wg , "irs-discuss@ietf.org" Thread-Topic: [irs-discuss] Fwd: I-D Action: draft-keyupate-bgp-services-01.txt Thread-Index: AQHNsKk9FnybAlUImUel5HkFkQ+9Kg== Date: Mon, 22 Oct 2012 23:01:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.173] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--50.073900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "David Ward \(wardd\)" , Kireeti Kompella Subject: Re: [Idr] [irs-discuss] Fwd: I-D Action: draft-keyupate-bgp-services-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, 22 Oct 2012 23:02:09 -0000 Hi Robert, Thanks for the comments. :) Comments inlined #Keyur. On 10/22/12 3:02 PM, "Robert Raszuk" wrote: >Dear authors, > >After reading this document I would like to observe that BGP seems to >not fit to the proposed application. Not that it is BGP fault, but the >service model required for service dissemination and discovery is much >better to be based on publish, subscribe, search primitives rather >then p2mp data base distribution propagation which is the BGP model. #Keyur: BGP has its own Pub sub model through use of RT. You could use it if you like. :) > >Putting gateways between service providers and service consumers is a >nice try to address the end point BGP protocol language barrier, but >it does not address the discovery model. #Keyur: The draft provides a way to have a service discovery. > >While one could argue that services could have attached RTs and >RT-Constrain could be used to push filter to only receive what is >necessary however current industry have already solved this problem in >a much more elegant way by using MAP servers and IF-MAP protocol >between producers and consumers. The database behind the MAP server >can be build in a very robust way (as compared to today's BGP state of >the art). #Keyur: I haven't seen a solution yet and so cant speak for it. ;) However, the draft provides BGP as a transport for service discovery and service advertisement. > >I would recommend for the authors to consider such alternatives and >possibly rewrite the proposal to make it fit the needs of this very >important class of application which is service discovery. #Keyur: Sure. Regards, Keyur > >Best regards, >R. > >---------- Forwarded message ---------- >From: >Date: Mon, Oct 22, 2012 at 11:13 PM >Subject: I-D Action: draft-keyupate-bgp-services-01.txt >To: i-d-announce@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Service Advertisement using BGP > Author(s) : Keyur Patel > Jan Medved > Rex Fernando > Burjiz Pithawala > Filename : draft-keyupate-bgp-services-01.txt > Pages : 12 > Date : 2012-10-22 > >Abstract: > A variety of services, such as NATs, firewalls, or caches, can be > embedded in a service provider network or instantiated in data > centers attached to the network. This document proposes extensions > to BGP that facilitate discovery of such service instances by > interested clients and allows dissemination of service information, > such as services capabilities or capacities, throughout the network > domain. The proposed extensions allow for optimal routing of > requests to service instances that can optimally serve them. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-keyupate-bgp-services > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-keyupate-bgp-services-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-keyupate-bgp-services-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >_______________________________________________ >irs-discuss mailing list >irs-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/irs-discuss From jie.dong@huawei.com Mon Oct 22 20:28:30 2012 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 2217F1F0C86 for ; Mon, 22 Oct 2012 20:28:30 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbnO0KNsa696 for ; Mon, 22 Oct 2012 20:28:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34DC41F0429 for ; Mon, 22 Oct 2012 20:28:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALX43304; Tue, 23 Oct 2012 03:28:28 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 04:28:21 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 11:28:27 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.86]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 11:28:15 +0800 From: Jie Dong To: idr wg Thread-Topic: New Version Notification for draft-zeng-idr-one-time-prefix-orf-03.txt Thread-Index: AQHNsBzv7wLG462F+EOEAK1fQBIgNJfGOpzw Date: Tue, 23 Oct 2012 03:28:14 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273259CA5E@szxeml504-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Idr] FW: New Version Notification for draft-zeng-idr-one-time-prefix-orf-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 03:28:30 -0000 RGVhciBhbGwsDQoNCkEgbmV3IHZlcnNpb24gb2YgZHJhZnQtemVuZy1pZHItb25lLXRpbWUtcHJl Zml4LW9yZiBoYXMgYmVlbiBzdWJtaXR0ZWQsIHdoaWNoIGluY2x1ZGVzIHRoZSB1c2UgY2FzZSB3 aXRoICJ0cmVhdC1hcy13aXRoZHJhdyIuDQoNCkFzIGFsd2F5cywgY29tbWVudHMgYXJlIHdlbGNv bWUuDQoNCkJlc3QgcmVnYXJkcywNCkppZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDIyLCAyMDEyIDI6MTggUE0NCj4g VG86IEppZSBEb25nDQo+IENjOiBqYWtvYi5oZWl0ekBlcmljc3Nvbi5jb207IGtleXVwYXRlQGNp c2NvLmNvbTsgaHVhbmd6bEBnc3RhLmNvbTsNCj4gcm9iLnNoYWtpckBidC5jb207IHplbmdxcXFx QGdtYWlsLmNvbQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXplbmctaWRyLW9uZS10aW1lLXByZWZpeC1vcmYtMDMudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXplbmctaWRyLW9uZS10aW1lLXByZWZpeC1vcmYtMDMudHh0DQo+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFmdC16ZW5nLWlkci1vbmUtdGltZS1wcmVm aXgtb3JmDQo+IFJldmlzaW9uOgkgMDMNCj4gVGl0bGU6CQkgT25lLXRpbWUgQWRkcmVzcy1QcmVm aXggQmFzZWQgT3V0Ym91bmQgUm91dGUgRmlsdGVyIGZvciBCR1AtNA0KPiBDcmVhdGlvbiBkYXRl OgkgMjAxMi0xMC0yMg0KPiBXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gTnVtYmVy IG9mIHBhZ2VzOiA4DQo+IFVSTDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtemVuZy1pZHItb25lLXRpbWUtcHJlZml4LW9yZi0wMy50eHQNCj4gU3RhdHVzOg0K PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXplbmctaWRyLW9uZS10aW1l LXByZWZpeC1vcmYNCj4gSHRtbGl6ZWQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXplbmctaWRyLW9uZS10aW1lLXByZWZpeC1vcmYtMDMNCj4gRGlmZjoNCj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemVuZy1pZHItb25lLXRpbWUtcHJlZml4LW9y Zi0wMw0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBP dXRib3VuZCBSb3V0ZXIgRmlsdGVyIChPUkYpIHR5cGUgZm9yDQo+ICAgIEJHUCwgdGVybWVkICJP bmUtdGltZSBBZGRyZXNzIFByZWZpeCBPdXRib3VuZCBSb3V0ZSBGaWx0ZXIiLCB3aGljaA0KPiAg ICB3b3VsZCBhbGxvdyBhIEJHUCBzcGVha2VyIHRvIHNlbmQgdG8gaXRzIEJHUCBwZWVyIGEgcm91 dGUgcmVmcmVzaA0KPiAgICByZXF1ZXN0IHdpdGggYSBzZXQgb2YgYWRkcmVzcy1wcmVmaXgtYmFz ZWQgZmlsdGVycyB0byBtYWtlIHRoZSBwZWVyDQo+ICAgIHNlbmQgb25seSB0aGUgc3BlY2lmaWMg cm91dGVzIG1hdGNoaW5nIHRoZSBmaWx0ZXJzIHRvIHRoZSBzcGVha2VyLg0KPiAgICBUaGlzIE9S Ri10eXBlIGVuYWJsZXMgYSBCR1Agc3BlYWtlciB0byByZS1hZHZlcnRpc2Ugc29tZSBzcGVjaWZp Yw0KPiAgICByb3V0ZXMgd2l0aG91dCB0aGUgbmVlZCBvZiBhZHZlcnRpc2luZyB0aGUgd2hvbGUg QWRqLVJJQi1PdXQgb2YgYQ0KPiAgICBzcGVjaWZpYyBhZGRyZXNzIGZhbWlseSwgd2hpY2ggbWFr ZXMgdGhlIHJvdXRlIHJlY292ZXJ5IGFuZCB0cm91YmxlDQo+ICAgIHNob290aW5nIG9wZXJhdGlv biBtb3JlIGVmZmljaWVudCBhbmQgYWxzbyByZWR1Y2VzIHRoZSBpbXBhY3Qgb24NCj4gICAgbmV0 d29yayBzdGFiaWxpdHkuICBUaGlzIGZpbHRlciBkb2VzIG5vdCBjaGFuZ2UgdGhlIG91dGJvdW5k IHJvdXRlDQo+ICAgIGZpbHRlcnMgb3IgcG9saWNpZXMgb24gdGhlIEJHUCBwZWVyIGFuZCBzaG91 bGQgb25seSBiZSB1c2VkIGZvciBvbmUtDQo+ICAgIHRpbWUgcm91dGUgZmlsdGVyaW5nLg0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From SRS0=B9rbxS=IO=ndzh.com=shares@srs.bis6.us.blackberry.com Wed Oct 17 13:21:55 2012 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 B803621F8698 for ; Wed, 17 Oct 2012 13:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUGIEKuve2aS for ; Wed, 17 Oct 2012 13:21:53 -0700 (PDT) Received: from smtp02.bis6.us.blackberry.com (smtp02.bis6.us.blackberry.com [74.82.85.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C25F21F86C7 for ; Wed, 17 Oct 2012 13:21:52 -0700 (PDT) Received: from b12.c6.bise6.blackberry ([192.168.0.112]) by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id q9HKLpSK027911; Wed, 17 Oct 2012 20:21:51 GMT Received: from 172.29.199.177 (cmp7.c6.bise6.blackberry [172.29.199.177]) by b12.c6.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id q9HKLnk4002223; Wed, 17 Oct 2012 20:21:49 GMT X-rim-org-msg-ref-id: 1517926197 Message-ID: <1517926197-1350505309-cardhu_decombobulator_blackberry.rim.net-592115365-@b27.c6.bise6.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <20120926090655.84AD3B1E002@rfc-editor.org> <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> In-Reply-To: <000b01cda0a3$ea0c4b00$4001a8c0@gateway.2wire.net> Sensitivity: Normal Importance: Normal To: "t petch" , "Yakov Rehkter" , tony.li@tony.li, skh@nexthop.com, stbryant@cisco.com, "Adrian Farrel" , jgs@juniper.net, "RFC Editor" From: shares@ndzh.com Date: Wed, 17 Oct 2012 20:21:45 +0000 Content-Type: text/plain MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 23 Oct 2012 10:02:41 -0700 Cc: shtyagi@microsoft.com, "idr@ietf. org" Subject: Re: [Idr] Spam:*******, Re: [Technical Errata Reported] RFC4271 (3366) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: shares@ndzh.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 21:24:23 -0000 VG9tOg0KDQpUaGFuayB5b3UgZm9yIGFsbCB5b3VyIGNvbW1lbnRzIG9uIHRoZSBzdGF0ZSBtYWNo aW5lLiAgRG8geW91IHdhbnQgYWxsIG15IGNvbW1lbnRzIG9uIHRoZSBsaXN0IG9yIG9mZi1saXN0 IHdpdGggc3VtbWFyaWVzIG9mIG91ciBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0Lg0KDQpZb3UgY2Fu IGluZmVyIGZyb20gdGhpcyBtZXNzYWdlIHRoYXQgSSBkaXNhZ3JlZSB3aXRoIHlvdSBvbiB5b3Vy IHN0YXRlIG1hY2hpbmUgY29tbWVudHMuDQoNClN1ZQ0KU2VudCB2aWEgQmxhY2tCZXJyeSBieSBB VCZUDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB0LnBldGNoIDxpZXRmY0Bi dGNvbm5lY3QuY29tPg0KRGF0ZTogVHVlLCAyIE9jdCAyMDEyIDE0OjQxOjM2IA0KVG86IDx5YWtv dkBqdW5pcGVyLm5ldD47IDx0b255LmxpQHRvbnkubGk+OyA8c2toQG5leHRob3AuY29tPjsgPHN0 YnJ5YW50QGNpc2NvLmNvbT47IDxhZHJpYW5Ab2xkZG9nLmNvLnVrPjsgPHNoYXJlc0BuZHpoLmNv bT47IDxqZ3NAanVuaXBlci5uZXQ+OyBSRkMgRXJyYXRhIFN5c3RlbTxyZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnPg0KQ2M6IDxzaHR5YWdpQG1pY3Jvc29mdC5jb20+OyA8cmZjLWVkaXRvckByZmMt ZWRpdG9yLm9yZz47IDxpZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBTcGFtOioqKioqKiosIFJlOiBb SWRyXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNDI3MSAoMzM2NikNCg0KRnJvbSB0 aGUgT3JpZ2luYWwgVGV4dCwgSSBpbmZlciB0aGF0IHRoaXMgcmVmZXJzIHRvIE9wZW5TZW50LCB3 aGVuIGV2ZW50DQoxOCBvY2N1cnMuDQoNClRoZSBOb3RlcyBzYXkNCg0KIkhvbGRUaW1lciBzaG91 bGQgb25seSBiZSB1c2VkIHRvIGNvbnRyb2wgdGltZSBpbiBiZXR3ZWVuIEJHUCBwYWNrZXRzLiAi DQoNClRoaXMgaXMgdHJ1ZSBidXQgaW4gT3BlblNlbnQgc3RhdGUgKHAuNjMpLCBhIEtFRVBBTElW RSBoYXMgYmVlbiBzZW50IChhcw0Kd2VsbCBhcyBhbiBPUEVOKSBzbyB0aGUgdGltZXIgc2hvdWxk IGJlIHJ1bm5pbmcuDQoNCiJBbHNvIGluIHRoaXMgY2FzZSBpdCBjYW4gbGVhZCB0byBjYXNlIGlu IEFDVElWRSBzdGF0ZSB3aGVyZSBIb2xkVGltZXINCmV4cGlyZXMgYmVmb3JlIHRoZSBDb25uZWN0 UmV0cnlUaW1lciBsZWFkaW5nIHRvIElETEUgc3RhdGUuIg0KDQpXZWxsLCBpdCB3aWxsIGxlYWQg dG8gQWN0aXZlIHN0YXRlIChwLjU5KSAtIHRoYXQgaXMgd2hhdCB0aGUgdGV4dCBzYXlzIC0NCmFu ZCBldmVudCAxMCwgSG9sZFRpbWVyIGV4cGlyZXMsIHdpbGwgdGhlbiB0YWtlIHlvdSB0byBJZGxl IHN0YXRlDQoocC42MykuDQoNClRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IHRoZSBIb2xkVGltZXIg aGFzIGJlZW4gc2V0IHRvIGEgbGFyZ2UgdmFsdWUsIDQNCm1pbnV0ZXMsIHdoaWNoIGlzIG11Y2gg Z3JlYXRlciB0aGFuIHRoZSBDb25uZWN0UmV0cnlUaW1lciAoOTBzKSBhbmQgaXQNCmlzIHRoZSBl eHBpcnkgb2YgdGhlIGxhdHRlciB0aGF0IHNob3VsZCB0YWtlIHlvdSBvdXQgb2YgQWN0aXZlIHN0 YXRlIHRvDQpDb25uZWN0IGFuZCB0aGVuY2UgdG8gT3BlblNlbnQgd2hlbiB0aGUgSG9sZFRpbWVy IHdpbGwgYmUgcmVzdGFydGVkLg0KTm90ZSB0aGF0IHRoZSByZWNlaXB0IG9mIGEgS0VFUEFMSVZF IChldmVudCAyNikgYWxzbyB0YWtlcyB5b3UgZnJvbQ0KQWN0aXZlIHRvIElkbGUgLSBJIHRoaW5r IHRoYXQgdGhlIHR3byBjYXNlcyBhcmUgc2ltaWxhciwgdGhhdCB0aGUgQkdQDQpjb25uZWN0aW9u IGRpZCBub3QgcmVhY2ggc2Vjb25kIGJhc2UuICBZb3UgYXJlIGluIHRyb3VibGUgZWl0aGVyIHdh eSBhbmQNCmJhY2sgdG8gSWRsZSBpcyB0aGUgc2FmZSB0aGluZyB0byBkby4NCg0KT2YgY291cnNl LCBpZiB5b3UgaWdub3JlIHRoYXQgYWR2aWNlIHRvIHNldCB0aGUgSG9sZFRpbWVyIHRvIGEgbGFy Z2UNCnZhbHVlIC0geW91IGhhdmUgeWV0IHRvIHJlY2VpdmUgYW4gT1BFTiBhbmQgc28gZG8gbm90 IGtub3cgd2hhdCB2YWx1ZQ0Kd2lsbCBiZSBhY2NlcHRhYmxlIHRvIHRoZSBwZWVyIC0gYW5kIHNl dCBpdCBpbnN0ZWFkIHRvIDNzLCB0aGVuIHllcywgeW91DQp3aWxsIGdldCBiYWNrIHRvIElkbGUg bW9yZSBvZnRlbiB0aGFuIGlzIGRlc2lyYWJsZS4NCg0KTm93YWRheXMsIHRoZXJlIGlzIGEgZ3Jl YXRlciB3aXNoIHRvIGtlZXAgQkdQIGNvbm5lY3Rpb25zIHVwLCBjb21wYXJlZA0KdG8gd2hlbiB3 ZSB3cm90ZSBSRkM0MjcxLCBidXQgSSB0aGluayB0aGF0LCBpbiB0aGlzIGNhc2UsIHRoZXJlIGlz DQpub3RoaW5nIHdvcnRoIGtlZXBpbmcgdXAgYW5kIGdvaW5nIGJhY2sgdG8gSWRsZSBpcyB0aGUg cmlnaHQgdGhpbmcgdG8NCmRvLg0KDQooSSBhbSBub3Qgc3VyZSB3aGF0IHRoZSBiZXN0IGRpc3Ry aWJ1dGlvbiBmb3IgdGhpcyBpcyBzbyBJIGhhdmUgdXNlZA0KJ1JlcGx5IEFsbCcgYnV0IGV4cGVj dCB0aGF0IHRoYXQgc2hvdWxkIGJlIHRyaW1tZWQgc29vbikuDQoNClRvbSBQZXRjaA0KDQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJSRkMgRXJyYXRhIFN5c3RlbSIgPHJm Yy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+DQpUbzogPHlha292QGp1bmlwZXIubmV0PjsgPHRvbnku bGlAdG9ueS5saT47IDxza2hAbmV4dGhvcC5jb20+Ow0KPHN0YnJ5YW50QGNpc2NvLmNvbT47IDxh ZHJpYW5Ab2xkZG9nLmNvLnVrPjsgPHNoYXJlc0BuZHpoLmNvbT47DQo8amdzQGp1bmlwZXIubmV0 Pg0KQ2M6IDxzaHR5YWdpQG1pY3Jvc29mdC5jb20+OyA8cmZjLWVkaXRvckByZmMtZWRpdG9yLm9y Zz47IDxpZHJAaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNiwgMjAxMiAx MDowNiBBTQ0KU3ViamVjdDogW0lkcl0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzQy NzEgKDMzNjYpDQoNCg0KPg0KPiBUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4g c3VibWl0dGVkIGZvciBSRkM0MjcxLA0KPiAiQSBCb3JkZXIgR2F0ZXdheSBQcm90b2NvbCA0IChC R1AtNCkiLg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBZ b3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCj4gaHR0cDovL3d3dy5yZmMt ZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9NDI3MSZlaWQ9MzM2Ng0KPg0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBUeXBlOiBUZWNobmljYWwNCj4g UmVwb3J0ZWQgYnk6IFNoYXNoYW5rIFR5YWdpIDxzaHR5YWdpQG1pY3Jvc29mdC5jb20+DQo+DQo+ IFNlY3Rpb246IDguMi4yDQo+DQo+IE9yaWdpbmFsIFRleHQNCj4gLS0tLS0tLS0tLS0tLQ0KPiBJ ZiBhIFRjcENvbm5lY3Rpb25GYWlscyBldmVudCAoRXZlbnQgMTgpIGlzIHJlY2VpdmVkLCB0aGUg bG9jYWwNCj4gICAgICAgc3lzdGVtOg0KPg0KPiAgICAgICAgIC0gY2xvc2VzIHRoZSBCR1AgY29u bmVjdGlvbiwNCj4NCj4gICAgICAgICAtIHJlc3RhcnRzIHRoZSBDb25uZWN0UmV0cnlUaW1lciwN Cj4NCj4gICAgICAgICAtIGNvbnRpbnVlcyB0byBsaXN0ZW4gZm9yIGEgY29ubmVjdGlvbiB0aGF0 IG1heSBiZSBpbml0aWF0ZWQNCmJ5DQo+ICAgICAgICAgICB0aGUgcmVtb3RlIEJHUCBwZWVyLCBh bmQNCj4NCj4gICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRvIEFjdGl2ZS4NCj4NCj4gQ29y cmVjdGVkIFRleHQNCj4gLS0tLS0tLS0tLS0tLS0NCj4gSWYgYSBUY3BDb25uZWN0aW9uRmFpbHMg ZXZlbnQgKEV2ZW50IDE4KSBpcyByZWNlaXZlZCwgdGhlIGxvY2FsDQo+ICAgICAgIHN5c3RlbToN Cj4NCj4gICAgICAgICAtIGNsb3NlcyB0aGUgQkdQIGNvbm5lY3Rpb24sDQo+DQo+ICAgICAgICAg LSBzZXRzIHRoZSBIb2xkVGltZXIgdG8gMCwNCj4NCj4gICAgICAgICAtIHJlc3RhcnRzIHRoZSBD b25uZWN0UmV0cnlUaW1lciwNCj4NCj4gICAgICAgICAtIGNvbnRpbnVlcyB0byBsaXN0ZW4gZm9y IGEgY29ubmVjdGlvbiB0aGF0IG1heSBiZSBpbml0aWF0ZWQNCmJ5DQo+ICAgICAgICAgICB0aGUg cmVtb3RlIEJHUCBwZWVyLCBhbmQNCj4NCj4gICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRv IEFjdGl2ZS4NCj4NCj4gTm90ZXMNCj4gLS0tLS0NCj4gSG9sZFRpbWVyIHNob3VsZCBvbmx5IGJl IHVzZWQgdG8gY29udHJvbCB0aW1lIGluIGJldHdlZW4gQkdQIHBhY2tldHMuDQo+IEFsc28gaW4g dGhpcyBjYXNlIGl0IGNhbiBsZWFkIHRvIGNhc2UgaW4gQUNUSVZFIHN0YXRlIHdoZXJlIEhvbGRU aW1lcg0KZXhwaXJlcyBiZWZvcmUgdGhlIENvbm5lY3RSZXRyeVRpbWVyIGxlYWRpbmcgdG8gSURM RSBzdGF0ZS4NCj4NCj4gSW5zdHJ1Y3Rpb25zOg0KPiAtLS0tLS0tLS0tLS0tDQo+IFRoaXMgZXJy YXRhIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVh c2UNCj4gdXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUgdmVy aWZpZWQgb3INCj4gcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVy aWZ5aW5nIHBhcnR5IChJRVNHKQ0KPiBjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFu ZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gUkZDNDI3MSAoZHJhZnQtaWV0Zi1pZHItYmdwNC0yNikN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVGl0bGUgICAgICAg ICAgICAgICA6IEEgQm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wgNCAoQkdQLTQpDQo+IFB1YmxpY2F0 aW9uIERhdGUgICAgOiBKYW51YXJ5IDIwMDYNCj4gQXV0aG9yKHMpICAgICAgICAgICA6IFkuIFJl a2h0ZXIsIEVkLiwgVC4gTGksIEVkLiwgUy4gSGFyZXMsIEVkLg0KPiBDYXRlZ29yeSAgICAgICAg ICAgIDogRFJBRlQgU1RBTkRBUkQNCj4gU291cmNlICAgICAgICAgICAgICA6IEludGVyLURvbWFp biBSb3V0aW5nDQo+IEFyZWEgICAgICAgICAgICAgICAgOiBSb3V0aW5nDQo+IFN0cmVhbSAgICAg ICAgICAgICAgOiBJRVRGDQo+IFZlcmlmeWluZyBQYXJ0eSAgICAgOiBJRVNHDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxp c3QNCj4gSWRyQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWRyDQo+DQoNCg0K From asreekan@cisco.com Tue Oct 23 11:20:33 2012 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 A8FAE11E80FE; Tue, 23 Oct 2012 11:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-vTm7O1vvOr; Tue, 23 Oct 2012 11:20:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1F47411E80FA; Tue, 23 Oct 2012 11:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5788; q=dns/txt; s=iport; t=1351016430; x=1352226030; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ufxO6kHE3O7lsIKglgX+94w2Zbp//NKsUlHnEjJhz4g=; b=UULhgIuC9dxDD+tQ5er84dmxjO0elCBvoJ4osjgtyHD6NVxccbWSWYOC Q7HJpAdyM2SI1hEXa6YBa9I3hzYHj4MKu7AyVhkeM0Ljc6WVwDxuE6ITN eORfgxx2KSBOJeU9dV6pC7r5TOvJ4Mz8ryQQgvsIxYb4ZLqSSdjZnP/3B U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJHfhlCtJXHB/2dsb2JhbABEwXCBCIIeAQEBBAEBAQ8BJzQDCBACAQgYChQQJwslAgQBDQUIGodhAQubf49ckC+LXyeFV2ADlwiNN4Frgm+BXB4GGA X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="134614459" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 23 Oct 2012 18:20:10 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9NIKAuc030547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 18:20:10 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 13:20:09 -0500 From: "Arjun Sreekantiah (asreekan)" To: Robert Raszuk , Randy Bush Thread-Topic: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Index: AQHNrNuLSOYjTNOD4UuRqk/qCgg5OJe+t84AgAV0XYCAAwd2QA== Date: Tue, 23 Oct 2012 18:20:09 +0000 Message-ID: <6CDE9DE8E74F58419C4C489FE0852B8F21DE01CE@xmb-rcd-x02.cisco.com> References: <507F745C.6000508@raszuk.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.139.154] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--49.969600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , L3VPN , "luay.jalil@verizon.com" Subject: Re: [Idr] draft-ymbk-l3vpn-origination-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, 23 Oct 2012 18:20:33 -0000 Robert, Answers inline... 1. Section "5.2. Provider/ASBR Based Validation/Authentication" indicates possible validation at the ASBR. First clearly it is not possible= to do that in option C which I think the draft should mention. In option C= you could try to describe such validation on EBGP peering VPNvX RRs. Assuming option-B (or option-C on RRs) how do I set validation policy (base= d on what value and parameter) that only some VPN customer's routes will be= subject for validation ? Same for PEs where subset of VPN customers reques= t validation. Or is the draft discussing only option-A ASBRs ? [Arjun] The example provided is for option B ASBR. In option C, as you say the same= could be performed on ebgp vpn RRs. This is meant to serve as an example i= llustrating usage of the scheme and not all inclusive list. The validation policy is agreed upon between the trusted provider and the V= PN customer on a per VPN basis. - This would necessarily mean all routes fr= om that VPN will be subject to validation. Since all CEs for that VPN would= be Part of the agreement, there is no need for perform validation on a sub= set of the routes. We would however allow for incremental deployment in wh= ich case some of the CEs are not upgraded to support the scheme in which ca= se the ASBR can define appropriate policy to accommodate these prefixes, th= is is a matter of implementation. 2. How much the NLRI validation on the ASBR option B or PE helps if RTs could = have been mangled on the way and validated or not routes will end up going = to wrong VPN sites ? [Arjun] If the scheme is implemented for the affected VPNs on the option B ASBR or= PE , then a mangled RT will result in the route being associated with the = wrong VPN and the signature digest validation would fail since the key id= entifier are unique per VPN, this way the mis-configuration of RTs is handl= ed as well.=20 Also typically, some of the providers already perform inbound validation o= f the RTs today by stripping RTs received and mapping them locally to the o= nes used for that VPN. Draft says: "ASBR2 is the trusted provider with whom CE1 has collaborated." How can one validate on ASBRs (or remote PEs) in the CE based key allocatio= n scheme ? What happens if two VPN customers with overlaping IP addresses w= ill choose the same keys on their CEs ? Note that CEs NLRI do not have noti= on of RDs and that ingress PEs convert IPv4 NLRIs from CE to VPNv4 NLRIs on= PEs adding RD. How can the signature be possibly meaningful anywhere else = that on the end PE's VRF or in the end site CE ? [Arjun] Please note that we have Key Identifier defined which will be unique per VP= N (can map to the vpn-id) and is also part of the signature digest. Hence i= n this case the digest will be different for the VPNs with overlapping add= ress/keys/ The validation on the ASBR/remote PE will be performed by retrie= ving the key associated with the key identifier and computing the appropri= ate signature digest so there is not context of RD in use here. 3. In case of validating on the PEs or CEs how does one handle extranets ? Is = the plan to share my keys with all extranet partners or use different key p= er each extranet VPN - case of per CE validation ? How would it work for PE based validation ? How would I carry multiples key= s if VPN chooses not to share his secret with some of his extranets ? [Arjun] Each VPN would have a unique key identifier and associated key. You could c= hoose to share the key and key identifier among extranet partners. Also you= could choose to define separate key identifier and associated key for priv= ate and shared prefixes The private keys would not be shared with extranet = partners. How do you associate a L3OPA to RTs ? Is the assumption in the draft that s= uch validation is to happen in the VPNvX space on during/past the import th= e VRFs ? [Arjun] For PE based validation, the validation will happen during the import of R= Ts using context of key identifiers defined for that VPN. 4. How would service provider be able to inject his own prefixes into VPN site= s for offering value add services (example VoIP gateway addresses) if custo= mer chooses CE based validation ? [Arjun] In the example provided the provider is serving as transit and not sourcing= any routes. If the service provider (SP) is injecting the routes then it m= akes sense to have the SP PE also being part of the scheme by computing the= signature checksum on behalf of the CE. Here it makes sense to define a ke= y identifier per VPN on the PEs/CEs and generate the signature digest on th= e VPN routes on the PE with the end CEs performing the validation as before= . 5. How do I propagate the result of ASBR or PE based validation to the VPN sit= e if such (say multihomed) site is connected to SP not via BGP but via an I= GP ? [Arjun] This is a BGP based scheme. One option you have in the scenario mentioned = above is to have the PE generate the signature digest on behalf of the VPN = site by configuring the key identifier per VPN on the PE and the validation= would be done on the PE. Thanks Arjun On Thu, Oct 18, 2012 at 5:15 AM, Robert Raszuk wrote: >> the keys are arbitrary. you can get ecerts from macdonalds for all=20 >> the spec cares. > > If this is so what is so novel about your draft if compared with=20 > already existing for over 10 years L3VPN WG below document ? > > http://tools.ietf.org/html/draft-ietf-l3vpn-auth-00 > > ? > > Thx, > R. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Tue Oct 23 12:01:24 2012 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 9551E11E8108 for ; Tue, 23 Oct 2012 12:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.73 X-Spam-Level: X-Spam-Status: No, score=-3.73 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlIU4GmPtdEN for ; Tue, 23 Oct 2012 12:01:24 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA3C11E80FE for ; Tue, 23 Oct 2012 12:01:09 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUIbpdIPMG0G9zmbi+SEZtPENQSlr8o/5@postini.com; Tue, 23 Oct 2012 12:01:09 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 23 Oct 2012 11:59:59 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 23 Oct 2012 11:59:59 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 23 Oct 2012 12:06:10 -0700 Received: from mail272-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 23 Oct 2012 18:59:55 +0000 Received: from mail272-va3 (localhost [127.0.0.1]) by mail272-va3-R.bigfish.com (Postfix) with ESMTP id 7662B16000FA for ; Tue, 23 Oct 2012 18:59:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -17 X-BigFish: PS-17(zzc85fhzz1202h1d1ah1d2ah1082kzz1033IL17326ah8275dhz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah139eh1441h14ddh1504h1537h1155h) Received: from mail272-va3 (localhost.localdomain [127.0.0.1]) by mail272-va3 (MessageSwitch) id 1351018793271677_17544; Tue, 23 Oct 2012 18:59:53 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.241]) by mail272-va3.bigfish.com (Postfix) with ESMTP id 4085E1E00047 for ; Tue, 23 Oct 2012 18:59:53 +0000 (UTC) Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 23 Oct 2012 18:59:51 +0000 Received: from ntatavossian-sslvpn-nc.jnpr.net (66.129.224.53) by pod51010.outlook.com (10.255.116.40) with Microsoft SMTP Server (TLS) id 14.16.224.5; Tue, 23 Oct 2012 18:59:50 +0000 From: John Scudder Content-Type: multipart/alternative; boundary="Apple-Mail=_113BCB0F-A8C7-4A5C-9BAE-417E1A68FB5E" Message-ID: Date: Tue, 23 Oct 2012 14:59:46 -0400 To: "idr@ietf.org List" MIME-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) X-Originating-IP: [66.129.224.53] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Idr] IDR IETF-85 draft agenda posted 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, 23 Oct 2012 19:01:24 -0000 --Apple-Mail=_113BCB0F-A8C7-4A5C-9BAE-417E1A68FB5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Our draft agenda is posted: http://www.ietf.org/proceedings/85/agenda/agenda-85-idr If you requested a slot, please confirm that you're listed. If you meant = to request one and haven't done it yet, now would be a good time. --John --Apple-Mail=_113BCB0F-A8C7-4A5C-9BAE-417E1A68FB5E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii" Our draft agenda is posted:

http://www.ietf.org/proceedings/85/agenda/agenda-85-idr

If you requested a slot, please confirm that you're listed. If you meant to request one and haven't done it yet, now would be a good time.

--John
--Apple-Mail=_113BCB0F-A8C7-4A5C-9BAE-417E1A68FB5E-- From rraszuk@gmail.com Tue Oct 23 15:00:37 2012 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 CC5E51F0C96; Tue, 23 Oct 2012 15:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOG0-4UncQ3S; Tue, 23 Oct 2012 15:00:37 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8181F0C92; Tue, 23 Oct 2012 15:00:36 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7076357iec.31 for ; Tue, 23 Oct 2012 15:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=2Sb9TCeb9dyHyuLB9kMpQuxkxs7Bqdb5RAuouj8kYyQ=; b=oVMhU++JXnT47UeX7tSNOatNWr36cgULyispV1hihesAt88zGwphyiH219U/2gsXT+ wtfhvEREn2SI1qU6BY59ZLnIJcQZMGcOg0PQ4EU8pFNfVMIixv5Gppi5101vUJjQVuEb Gs2QLj6bNBWdtYkI+x409bXKdAnoS6Qg00oUXq1iAJG3TdGbfy1Eab+fuj5KhlYjxRy9 2Z+R8fPBHiGzc93BV7gR+YvIKtdVTlRQNSbRHqDAqYEG9ntN397Kd/4VADIXnNWZnLYa zhzSFX7zB0/xiVXqOMSTtwwoPkaIA5QDHuLw7Ahdh52r9yItRKPikLCiGJrutyfzitu2 qnKg== MIME-Version: 1.0 Received: by 10.42.109.194 with SMTP id m2mr12050689icp.48.1351029636645; Tue, 23 Oct 2012 15:00:36 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Tue, 23 Oct 2012 15:00:36 -0700 (PDT) In-Reply-To: <6CDE9DE8E74F58419C4C489FE0852B8F21DE01CE@xmb-rcd-x02.cisco.com> References: <507F745C.6000508@raszuk.net> <6CDE9DE8E74F58419C4C489FE0852B8F21DE01CE@xmb-rcd-x02.cisco.com> Date: Wed, 24 Oct 2012 00:00:36 +0200 X-Google-Sender-Auth: vrVvD-ur2_Y5CVa_q0iTLUGwu-8 Message-ID: From: Robert Raszuk To: "Arjun Sreekantiah (asreekan)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: idr wg , L3VPN , "luay.jalil@verizon.com" Subject: Re: [Idr] draft-ymbk-l3vpn-origination-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, 23 Oct 2012 22:00:37 -0000 Hi Arjun, > The validation policy is agreed upon between the trusted provider and the= VPN > customer on a per VPN basis. Let's observe that option B ASBR you are referring to has no per VPN basis notion. What you are describing is not possible to accomplish as said ASBR would have to perform the validation based on the subset of VPNv4 or VPNv6 routes based on the local RT import. Unless ASBR option B is also acting as local PE or is configured with A+B or option D there is no per VRF import based on the RTs. Please provide a sample configuration how are you going to enable L3VPN origin validation on ASBR " on a per VPN basis" ? > 2. > How much the NLRI validation on the ASBR option B or PE helps if RTs coul= d have been mangled on the way and validated or not routes will end up goin= g to wrong VPN sites ? > [Arjun] > If the scheme is implemented for the affected VPNs on the option B ASBR = or PE , > then a mangled RT will result in the route being associated with the wron= g VPN RTs do not associate routes to VPNs on the ASBRs. > and the signature digest validation would fail since the key identifier= are unique per > VPN, this way the mis-configuration of RTs is handled as well. The draft clearly provides the option to assign such signature on the CE. CEs are owned by customers and they may choose the same key id. > Also typically, some of the providers already perform inbound validation= of the RTs > today by stripping RTs received and mapping them locally to the ones used= for that > VPN. RT mapping if at all used in production other then via option D does not solve anything. > Draft says: "ASBR2 is the trusted provider with whom CE1 has collaborated= ." > How can one validate on ASBRs (or remote PEs) in the CE based key allocat= ion scheme ? What happens if two VPN customers with overlaping IP addresses= will choose the same keys on their CEs ? Note that CEs NLRI do not have no= tion of RDs and that ingress PEs convert IPv4 NLRIs from CE to VPNv4 NLRIs = on PEs adding RD. How can the signature be possibly meaningful anywhere els= e that on the end PE's VRF or in the end site CE ? > [Arjun] > Please note that we have Key Identifier defined which will be unique per = VPN (can map to the vpn-id) and is also part of the signature digest. The draft clearly provides the option to assign such signature on the CE. CEs are owned by customers and they may choose the same key id and the same prefix. > Hence in this case the digest will be different for the VPNs with overla= pping > address/keys/ The validation on the ASBR/remote PE will be performed by r= etrieving > the key associated with the key identifier and computing the appropriate= signature > digest so there is not context of RD in use here. On ASBR and global VPNv4 table RD is part of the NLRI. > 3. > In case of validating on the PEs or CEs how does one handle extranets ? I= s the plan to share my keys with all extranet partners or use different key= per each extranet VPN - case of per CE validation ? > How would it work for PE based validation ? How would I carry multiples k= eys if VPN chooses not to share his secret with some of his extranets ? > [Arjun] > Each VPN would have a unique key identifier and associated key. You could > choose to share the key and key identifier among extranet partners. Also = you could > choose to define separate key identifier and associated key for private a= nd shared > prefixes The private keys would not be shared with extranet partners. Please provide encoding to carry more then one key with the prefix so my keys are not shared with my extranet partners. > 4. > How would service provider be able to inject his own prefixes into VPN si= tes for offering value add services (example VoIP gateway addresses) if cus= tomer chooses CE based validation ? > [Arjun] > In the example provided the provider is serving as transit and not sourci= ng any > routes. Then such example is not that practical. > If the service provider (SP) is injecting the routes then it makes sense = to have the > SP PE also being part of the scheme by computing the signature checksum o= n > behalf of the CE. The question was clearly for CE based validation. > 5. > How do I propagate the result of ASBR or PE based validation to the VPN s= ite if such (say multihomed) site is connected to SP not via BGP but via an= IGP ? > [Arjun] > This is a BGP based scheme. That's the problem with this scheme. L3VPN are not only BGP based on the CE-CE basis. Origin validation could be made to work for Internet (assuming there is interest) however as documented it has number of architectural and practical problems to solve for L3VPN architecture. Best regards, R. From asreekan@cisco.com Tue Oct 23 18:27:56 2012 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 39DF711E814E; Tue, 23 Oct 2012 18:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSW5nBG6ZW-n; Tue, 23 Oct 2012 18:27:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1657911E8149; Tue, 23 Oct 2012 18:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6860; q=dns/txt; s=iport; t=1351042075; x=1352251675; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QNwPMIN+js6krDBAkI72/Xsd8cLcZb9QexG9Wq7fUCE=; b=Ziu/rAXC5tU6mpVBS9x7AgrezFyU1Xz5OtDsz14smyzk7RUMz4WZi0r6 E9cpdJOTHXsEysHjTAGPvlrqJVmYawwdZG5ogjvLpNysXlu1r1m6C+10h sVXxHuy+DdHQrYkY7+z10qJuLTpqkZFu7lpytNnWUHh9RBpvW3eUmxZsR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALVDh1CtJV2d/2dsb2JhbABEwgOBCIIeAQEBAwESASc3CAUHBAIBCBEBAwEBCxQJByERFAMGCAIEDgUIEweHUAMJBQGbGJFshDENiVSKeWeFfmADlB2MfoMlgWuCYg2BXB4GGA X-IronPort-AV: E=Sophos;i="4.80,638,1344211200"; d="scan'208";a="134707796" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 24 Oct 2012 01:27:54 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9O1RsPv002694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Oct 2012 01:27:54 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 20:27:54 -0500 From: "Arjun Sreekantiah (asreekan)" To: Robert Raszuk Thread-Topic: [Idr] draft-ymbk-l3vpn-origination-00.txt Thread-Index: AQHNrNuLSOYjTNOD4UuRqk/qCgg5OJe+t84AgAV0XYCAAwd2QIAAmiIA///U78A= Date: Wed, 24 Oct 2012 01:27:54 +0000 Message-ID: <6CDE9DE8E74F58419C4C489FE0852B8F21DE0656@xmb-rcd-x02.cisco.com> References: <507F745C.6000508@raszuk.net> <6CDE9DE8E74F58419C4C489FE0852B8F21DE01CE@xmb-rcd-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.139.154] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--52.105600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , L3VPN , "luay.jalil@verizon.com" Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 01:27:56 -0000 Robert, More replies below. -----Original Message----- From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz= uk Sent: Tuesday, October 23, 2012 3:01 PM To: Arjun Sreekantiah (asreekan) Cc: Randy Bush; idr wg; L3VPN; luay.jalil@verizon.com Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt >Hi Arjun, >> The validation policy is agreed upon between the trusted provider and=20 >> the VPN customer on a per VPN basis. > >Let's observe that option B ASBR you are referring to has no per VPN basis= notion. What you are describing is not possible to accomplish as said ASBR= would have to perform the validation based on the subset of >VPNv4 or VPNv6 routes based on the local RT import. >Unless ASBR option B is also acting as local PE or is configured with >A+B or option D there is no per VRF import based on the RTs. [Arjun] The ASBR can still perform the validation based on configured key-id and as= sociated key without having to perform any import operation. As explained = before you can have the key-id map to a vpn-id and only the key-id and asso= ciated keys need to be defined on the ASBR. >Please provide a sample configuration how are you going to enable L3VPN or= igin validation on ASBR " on a per VPN basis" ? [Arjun] We will pass it you as soon as we have a implementation ready. > 2. >> How much the NLRI validation on the ASBR option B or PE helps if RTs cou= ld have been mangled on the way and validated or not routes will end up goi= ng to wrong VPN sites ? >> [Arjun] >> If the scheme is implemented for the affected VPNs on the option B=20 >> ASBR or PE , then a mangled RT will result in the route being=20 >> associated with the wrong VPN >RTs do not associate routes to VPNs on the ASBRs. [Arjun] We are not suggesting using RTs to do that in this scheme, just use the con= text of the key identifier to retrieve the associated key and verify the si= gnature digest. >> and the signature digest validation would fail since the key=20 >> identifier are unique per VPN, this way the mis-configuration of RTs is = handled as well. >The draft clearly provides the option to assign such signature on the CE. = CEs are owned by customers and they may choose the same key id. [Arjun] For the provider validation case, the CE will still need to agree upon keys= and key-id with the provider and the provider can ensure uniqueness of the= key-id across vpns. For the CE-CE Case, the secret key associated with key-id is private to the CEs in that V= PN and the signature digest will be unique across CEs . >> Also typically, some of the providers already perform inbound=20 >> validation of the RTs today by stripping RTs received and mapping them=20 >> locally to the ones used for that VPN. >RT mapping if at all used in production other then via option D does not s= olve anything. [Arjun] It ensures improper RTs are discarded. >> Draft says: "ASBR2 is the trusted provider with whom CE1 has collaborate= d." >> How can one validate on ASBRs (or remote PEs) in the CE based key alloca= tion scheme ? What happens if two VPN customers with overlaping IP addresse= s will choose the same keys on their CEs ? Note that >>CEs NLRI do not have= notion of RDs and that ingress PEs convert IPv4 NLRIs from CE to VPNv4 NLR= Is on PEs adding RD. How can the signature be possibly meaningful anywhere = else that on the end PE's VRF or >>in the end site CE ? > >[Arjun] > >Please note that we have Key Identifier defined which will be unique per= VPN (can map to the vpn-id) and is also part of the signature digest. >The draft clearly provides the option to assign such signature on the CE. = CEs are owned by customers and they may choose the same key id and the same= prefix. [Arjun] See above. The secret key to generate the digest is still private to the CE= s in that VPN. >> Hence in this case the digest will be different for the VPNs with=20 >> overlapping address/keys/ The validation on the ASBR/remote PE will be=20 >> performed by retrieving the key associated with the key identifier=20 >> and computing the appropriate signature digest so there is not context o= f RD in use here. >On ASBR and global VPNv4 table RD is part of the NLRI. [Arjun] Yes but I do not see what your point is here. >> 3. >> In case of validating on the PEs or CEs how does one handle extranets ? = Is the plan to share my keys with all extranet partners or use different ke= y per each extranet VPN - case of per CE validation ? >> How would it work for PE based validation ? How would I carry multiples = keys if VPN chooses not to share his secret with some of his extranets ? >> [Arjun] >> Each VPN would have a unique key identifier and associated key. You=20 >> could choose to share the key and key identifier among extranet=20 >> partners. Also you could choose to define separate key identifier and=20 >> associated key for private and shared prefixes The private keys would no= t be shared with extranet partners. >Please provide encoding to carry more then one key with the prefix so my k= eys are not shared with my extranet partners. [Arjun] There is no need to for encoding more than one key with a single prefix her= e. The prefix is either private when it is associated with a private key or= shared for which it has a shared key defined. > 4. >> How would service provider be able to inject his own prefixes into VPN s= ites for offering value add services (example VoIP gateway addresses) if cu= stomer chooses CE based validation ? >> [Arjun] >> In the example provided the provider is serving as transit and not=20 >> sourcing any routes. >> If the service provider (SP) is injecting the routes then it makes=20 > >sense to have the SP PE also being part of the scheme by computing the=20 > >signature checksum on behalf of the CE. >The question was clearly for CE based validation. [Arjun] In this case, The PE can sign the prefixes in this case using locally and d= efined key ID and key and share it with the CEs. >> 5. >> How do I propagate the result of ASBR or PE based validation to the VPN = site if such (say multihomed) site is connected to SP not via BGP but via a= n IGP ? >> [Arjun] >> This is a BGP based scheme. >That's the problem with this scheme. L3VPN are not only BGP based on the C= E-CE basis. >Origin validation could be made to work for Internet (assuming there is in= terest) however as documented it has number of architectural and practical = problems to solve for L3VPN architecture. [Arjun] I would disagree - we can work out a solution in the l3vpn case as well - s= uggest we sync up at the upcoming meeting in Atlanta if you have further c= oncerns. Thanks Arjun Best regards, R. From rraszuk@gmail.com Wed Oct 24 00:27:33 2012 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 534AA21F84AF; Wed, 24 Oct 2012 00:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOjzxZ0hP3jt; Wed, 24 Oct 2012 00:27:32 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A19321F84B5; Wed, 24 Oct 2012 00:27:32 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so290315iec.31 for ; Wed, 24 Oct 2012 00:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iU7U4ZpnZJ0Dychhz9TUxV28dN2AwSO20RW3hdWEkOk=; b=Ju+hAJDDCJdWgFiqkXfnk/dXLkA6OmSOXqz4O3XPGASC4Ck+lvM2s7RZNCY7zwkjfR 9PSfJbK3C95Bd12BKKdheou4cERzY2XP6otn3kdiVoyJKj3780WhNziaemfhzowT8nDD dbQJI2Q1VZxRq3jbFvmDJt9zRp3V5G9gdOQalOJfHSPfaW4YlXB8HSImHSTeNOIrj1oJ 2hK+BISGjz9CZd29W5TkfV8T8hiX7sz0hVnswuDzkxLyYlesTEXXBHFhgwB89rzyknLc 5U30q1S+3KZeODmsHm9OijKD7pg7LZCfT9b133PaMKkCT3RkKQWp1y0WQyHQSXTCLLcE wbjQ== MIME-Version: 1.0 Received: by 10.50.87.227 with SMTP id bb3mr1643245igb.15.1351063651849; Wed, 24 Oct 2012 00:27:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Wed, 24 Oct 2012 00:27:31 -0700 (PDT) In-Reply-To: <6CDE9DE8E74F58419C4C489FE0852B8F21DE0656@xmb-rcd-x02.cisco.com> References: <507F745C.6000508@raszuk.net> <6CDE9DE8E74F58419C4C489FE0852B8F21DE01CE@xmb-rcd-x02.cisco.com> <6CDE9DE8E74F58419C4C489FE0852B8F21DE0656@xmb-rcd-x02.cisco.com> Date: Wed, 24 Oct 2012 09:27:31 +0200 X-Google-Sender-Auth: 8o8JP5oTubNA6X4OfoLP849wfAA Message-ID: From: Robert Raszuk To: "Arjun Sreekantiah (asreekan)" Content-Type: text/plain; charset=ISO-8859-1 Cc: idr wg , L3VPN , "luay.jalil@verizon.com" Subject: Re: [Idr] draft-ymbk-l3vpn-origination-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 07:27:33 -0000 > [Arjun] > The ASBR can still perform the validation based on configured key-id and associated key > without having to perform any import operation. As explained before you can have the key- > id map to a vpn-id and only the key-id and associated keys need to be defined on the > ASBR. There is no such a thing in VPNv4/v6 advertisement like "vpn-id". >>RTs do not associate routes to VPNs on the ASBRs. > > [Arjun] > We are not suggesting using RTs to do that in this scheme, just use the context of the > key identifier to retrieve the associated key and verify the signature digest. That is precisely the main issue with your proposal. You would be much better off with adding RT validation (*based on the very same scheme as you proposed for NLRI validation in this draft*) Thx, R. From danny@tcb.net Wed Oct 24 08:53:49 2012 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 9E93E21F8CBB for ; Wed, 24 Oct 2012 08:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.501 X-Spam-Level: X-Spam-Status: No, score=-101.501 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E65qSO66bnI3 for ; Wed, 24 Oct 2012 08:53:49 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABAB21F8CB8 for ; Wed, 24 Oct 2012 08:53:49 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 88EC91CEA for ; Wed, 24 Oct 2012 15:53:48 +0000 (UTC) Received: from [172.17.44.208] (unknown [66.18.5.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 600BD1B3C; Wed, 24 Oct 2012 09:53:48 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: <20120912214338.30319.35955.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2012 11:54:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E458910-F715-45B2-8757-26E52A8AED08@tcb.net> References: <20120912214338.30319.35955.idtracker@ietfa.amsl.com> To: "idr@ietf. org" , "John G. Scudder" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Oct 24 09:53:48 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50880f0c199631323221410 X-DSPAM-Factors: 27, do+#+one, 0.40000, regarding+#+#+#+S, 0.40000, have+#+#+#+the, 0.40000, Through+#+#+#+analysis, 0.40000, I+#+have, 0.40000, of+#+#+learned, 0.40000, explicit+#+a, 0.40000, of+#+IBGP, 0.40000, peer+#+#+redundant, 0.40000, this+#+in, 0.40000, for+#+#+routes, 0.40000, a+#+RR, 0.40000, To*Scudder+jgs, 0.40000, routes+#+this, 0.40000, reflected+#+#+#+suppressed, 0.40000, peer+#+MAY, 0.40000, never+#+behavior, 0.40000, To*ietf.+#+#+ietf.org, 0.40000, intuitive+I, 0.40000, EBGP+learned, 0.40000, EBGP+learned, 0.40000, it+#+#+any, 0.40000, 30+32, 0.40000, A+#+#+#+as, 0.40000, To*idr+ietf., 0.40000, how+#+#+#+the, 0.40000, the+#+#+learned, 0.40000 Subject: [Idr] Question about draft-scudder-idr-ebgp-rr 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, 24 Oct 2012 15:53:49 -0000 John,=20 The two specific updates in this I-D seem reasonable to me. It's = interesting that 4456 never stated behavior for an RR for EBGP-learned = routes, (it seems intuitive), I suspect you need to be explicit for a = reason.=20 I do have one question with the current version of the draft, regarding = this text in S.4: A RR that serves as an EBGP speaker SHOULD have an IBGP peering with any redundant RR. It SHOULD advertise the same EBGP-learned routes over this peering that it advertises to any other IBGP peer. It MAY suppress reflection of any IBGP-learned routes to the redundant RR. As you might suspect, I like this recommendation a lot [1]. That said, = I'm wondering how would you expect the local RR to know that the peer is = a "redundant RR" and that reflected routes could be suppressed? Through = static configuration? Dynamic analysis of CLUSTER_LIST CLUSTER_IDs in = received updates? Or..? Thanks,=20 -danny [1] Slides 30-32 here: = =20= From jgs@juniper.net Wed Oct 24 10:10:06 2012 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 0AC7421F867B for ; Wed, 24 Oct 2012 10:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.311 X-Spam-Level: X-Spam-Status: No, score=-3.311 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrurDQmkZ1LE for ; Wed, 24 Oct 2012 10:10:05 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id EF8AE21F85ED for ; Wed, 24 Oct 2012 10:10:04 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUIgg7GWhu2vKSuKqlJrBaxsuDJL19Wux@postini.com; Wed, 24 Oct 2012 10:10:05 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 24 Oct 2012 10:07:44 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 24 Oct 2012 10:07:43 -0700 Received: from TX2EHSOBE010.bigfish.com (65.55.88.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 24 Oct 2012 10:12:28 -0700 Received: from mail189-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 24 Oct 2012 17:05:26 +0000 Received: from mail189-tx2 (localhost [127.0.0.1]) by mail189-tx2-R.bigfish.com (Postfix) with ESMTP id C461A800142 for ; Wed, 24 Oct 2012 17:05:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zz98dI9371I1432Izz1202h1d1ah1d2ah1082kzz8275chz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h1155h) Received: from mail189-tx2 (localhost.localdomain [127.0.0.1]) by mail189-tx2 (MessageSwitch) id 1351098324501400_27499; Wed, 24 Oct 2012 17:05:24 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.249]) by mail189-tx2.bigfish.com (Postfix) with ESMTP id 73C781A0220; Wed, 24 Oct 2012 17:05:24 +0000 (UTC) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 24 Oct 2012 17:05:23 +0000 Received: from ntatavossian-sslvpn-nc.jnpr.net (66.129.224.53) by pod51010.outlook.com (10.255.84.38) with Microsoft SMTP Server (TLS) id 14.16.224.5; Wed, 24 Oct 2012 17:05:22 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: "John G. Scudder" In-Reply-To: <5E458910-F715-45B2-8757-26E52A8AED08@tcb.net> Date: Wed, 24 Oct 2012 13:05:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20120912214338.30319.35955.idtracker@ietfa.amsl.com> <5E458910-F715-45B2-8757-26E52A8AED08@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1498) X-Originating-IP: [66.129.224.53] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TCB.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "idr@ietf. org" Subject: Re: [Idr] Question about draft-scudder-idr-ebgp-rr 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, 24 Oct 2012 17:10:06 -0000 On Oct 24, 2012, at 11:54 AM, Danny McPherson wrote: >=20 > John,=20 > The two specific updates in this I-D seem reasonable to me. It's = interesting that 4456 never stated behavior for an RR for EBGP-learned = routes, (it seems intuitive), I suspect you need to be explicit for a = reason.=20 Yes -- apparently what is intuitive to you, is not to everyone. Such is = the way of standards... > I do have one question with the current version of the draft, = regarding this text in S.4: >=20 > A RR that serves as an EBGP speaker SHOULD have an IBGP peering with > any redundant RR. It SHOULD advertise the same EBGP-learned routes > over this peering that it advertises to any other IBGP peer. It MAY > suppress reflection of any IBGP-learned routes to the redundant RR. >=20 > As you might suspect, I like this recommendation a lot [1]. That = said, I'm wondering how would you expect the local RR to know that the = peer is a "redundant RR" and that reflected routes could be suppressed? = Through static configuration? Dynamic analysis of CLUSTER_LIST = CLUSTER_IDs in received updates? Or..? Static configuration, although as you point out it's possible in = principle to work it out from analyzing received CLUSTER_LISTs.=20 --John= From ju1738@att.com Wed Oct 24 10:51:57 2012 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 37CBC21F8853 for ; Wed, 24 Oct 2012 10:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72Xavk2c5Rml for ; Wed, 24 Oct 2012 10:51:56 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2921F8850 for ; Wed, 24 Oct 2012 10:51:54 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 9ba28805.0.303426.00-458.823781.nbfkord-smmo08.seg.att.com (envelope-from ); Wed, 24 Oct 2012 17:51:54 +0000 (UTC) X-MXL-Hash: 50882aba4f056fc4-ee0218aa5c3ea10a9320b5312c434ea4bbd864c3 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9OHpq92007504; Wed, 24 Oct 2012 10:51:53 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q9OHphi5007256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 10:51:45 -0700 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint03.pst.cso.att.com (RSA Interceptor); Wed, 24 Oct 2012 10:51:35 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 13:51:34 -0400 From: "UTTARO, JAMES" To: "'John G. Scudder'" , Danny McPherson Thread-Topic: [Idr] Question about draft-scudder-idr-ebgp-rr Thread-Index: AQHNsgp0n2Tsp0rVUEGdxHvQpxFFypfIvDpg Date: Wed, 24 Oct 2012 17:51:34 +0000 Message-ID: References: <20120912214338.30319.35955.idtracker@ietfa.amsl.com> <5E458910-F715-45B2-8757-26E52A8AED08@tcb.net> In-Reply-To: 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 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=fKeOK+me c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=g8Qva45Ca7EA:10 a=zi-y6p43X_oA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=jx5LMoF7dzEA:10 a=48vgC7mUAAAA:8 a=-y3SfPV3AAAA:8] X-AnalysisOut: [ a=jtB3krBsd7NtyA4vdzoA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=1plkUffeZn0A:10] Cc: "idr@ietf. org" Subject: Re: [Idr] Question about draft-scudder-idr-ebgp-rr 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, 24 Oct 2012 17:51:57 -0000 John, Draft looks good... Thanks, Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John = G. Scudder Sent: Wednesday, October 24, 2012 1:05 PM To: Danny McPherson Cc: idr@ietf. org Subject: Re: [Idr] Question about draft-scudder-idr-ebgp-rr On Oct 24, 2012, at 11:54 AM, Danny McPherson wrote: >=20 > John,=20 > The two specific updates in this I-D seem reasonable to me. It's intere= sting that 4456 never stated behavior for an RR for EBGP-learned routes, (i= t seems intuitive), I suspect you need to be explicit for a reason.=20 Yes -- apparently what is intuitive to you, is not to everyone. Such is the= way of standards... > I do have one question with the current version of the draft, regarding t= his text in S.4: >=20 > A RR that serves as an EBGP speaker SHOULD have an IBGP peering with > any redundant RR. It SHOULD advertise the same EBGP-learned routes > over this peering that it advertises to any other IBGP peer. It MAY > suppress reflection of any IBGP-learned routes to the redundant RR. >=20 > As you might suspect, I like this recommendation a lot [1]. That said, I= 'm wondering how would you expect the local RR to know that the peer is a "= redundant RR" and that reflected routes could be suppressed? Through stati= c configuration? Dynamic analysis of CLUSTER_LIST CLUSTER_IDs in received = updates? Or..? Static configuration, although as you point out it's possible in principle = to work it out from analyzing received CLUSTER_LISTs.=20 --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr